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FOREWORD 


Many  transit  operators  have  been  frustrated  in  their  attempt  to 
implement  systematic  service  evaluation  systems  because  they  have 
not  been  able  to  efficiently  collect  the  required  information.  In 
response  to  these  needs  automated  data  collection  techniques  were 
developed  in  the  last  fifteen  years.     Today,  more  than  twenty 
transit  agencies  in  North  America  have  implemented  automated  data 
collection  systems.     All  of  these  applications  use  automatic 
passenger  counters  or  APCs. 

This  report  on  APCs  was  prepared  by  the  Lane  Transit  District  in 
Eugene,  Oregon.     It  evaluates  the  capabilities,  cost  and  benefits 
of  APCs  and  presents  a  broad  range  of  detailed  technical 
information  on  existing  APC  applications.     We  believe  that  this 
report  will  benefit  transit  agencies  that  are  considering 
incorporating  APCs  into  their  data  collection  systems. 
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Chapter  One 
Introduction 


In  recent  years,  concern  for  air  pollution  and  depleting  energy  resources,  gas 
shortages,  gas  prices,  traffic  congestion  and  parking  shortages  have  created 
incentives  for  more  people  to  ride  the  bus.  The  resulting  change  in  demand  for 
transit  service  has  increased  the  importance  of  transit  system  surveillance. 
Growing  fiscal  pressures  and  a  change  in  planning  emphasis  from  capital 
intensive  improvements  to  short-range  transit  efficiency  actions  further 
contribute  to  transit  agencies'  need  for  reliable  indicators  of  how  well  the 
systems  are  performing.  (Mul ti systems  Interim  Report.  1982). 

To  effectively  evaluate  system  performance  and  identify  potential  improvements, 
public  transit  agencies  require  a  significant  amount  of  information.  Collecting 
and  evaluating  this  information  is  critical  for  an  effective  transit  decision- 
making process.  In  general,  there  are  three  categories  of  data  used  by  transit 
agencies: 

(1)  passenger     loading     profiles     used     to     determine     overloading  and 
underuti 1 ization; 

(2)  time  performance  indicators  used  in  route  scheduling;  and 

(3)  system  performance  indicators  used  by  transit  management. 

This  information  is  used  at  different  levels  of  disaggregation  for  transit 
planning,  scheduling,  and  management. 

The  methods  employed  by  transit  agencies  to  obtain  information  vary  from  agency 
to  agency.  The  most  common  techniques  include  ride  checks,  point  checks,  and 
driver  counts.  These  methods  involve  the  use  of  manual  data  collection.  The 
people  performing  these  tasks  are  either  retained  on  staff  full-time  or  part- 
time  or  are  hired  and  trained  periodically  as  the  need  for  data  arises.  The 
costs  associated  with  manual  methods  are  high,  particularly  for  large  agencies. 

Several  problems  with  manual  data  collection  techniques  have  been  identified  by 
agencies.  Primary  among  these  are:  poor  reliability,  low  accuracy,  operational 
problems,  relatively  high  costs,  and  long  turnaround  time  between  observation 
and  reporting  of  events  (Mul ti systems  Interim  Report.  1982).  In  response  to  this 
need  for  more  effective,  reliable,  and  cost  efficient  data  collection  methods, 
automated  data  collection  techniques  were  developed  in  the  1970' s.  Today,  at 
least  seventeen  transit  agencies  in  North  America  have  implemented  automated 
data  collection  systems.  All  of  these  applications  use  automatic  passenger 
counters  or  APC. 

Basically,  APCs  involve  the  use  of  electronic  devices  or  "sensors"  to  detect 
transit  passenger  activity.  Data  on  the  number  of  passengers  boarding  and 
alighting  (deboarding)  the  bus  and  the  location  of  that  activity  are  accumulated 
and  stored  in  a  microprocessor  on-board  the  bus.  These  data  are  later 
transferred  (either  manually  or  automatically)  to  a  central,  stationary 
computer  for  data  processing  and  report  generation.  Prior  to  the  development  of 
APCs,  these  tasks  were  performed  exclusively  by  people.  Today,  many  of  the 
agencies  using  APCs  have  limited  or  discontinued  manual  data  collection 
activities. 
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This  study  evaluates  the  capabilities,  costs,  and  benefits  of  automated  data 
collection  techniques  in  collecting  and  analyzing  ridership  information 
essential  to  public  transit  planning  and  management.  This  evaluation  presents 
a  broad  range  of  detailed  and  technical  information  on  APCs  which  will  be  a 
resource  for  agencies  researching  alternative  data  collection  techniques.  In 
addition,  the  discussion  on  APC  system  implementation  will  benefit  agencies 
planning  a  conversion  from  manual  to  automated  data  collection  methods. 


1.1  Background 

The  first  automated  information  systems  for  transit  agencies  were  designed  to 
provide  data  in  real-time  for  vehicle  monitoring  and  emergency  response.  "Real- 
time" means  that  the  time  and  location  data  are  transmitted  over  the  radio 
continuously  while  buses  are  on  the  road.  As  the  buses  move  along  their 
scheduled  routes,  their  activity  is  displayed  on  screens  in  a  central  office. 
These  systems  are  known  as  AVM  or  automatic  vehicle  monitoring  systems. 

Unlike  AVM  systems,  APCs  are  report-oriented  information  systems  used  by 
planning,  scheduling,  marketing,  and  transit  management.  APCs  count  the  number 
of  passengers  boarding  and  deboarding  the  bus  and  the  time  and  location  of  that 
activity.  APCs  are  "off-line"  as  opposed  to  "real-time"  systems.  This  means 
that  the  data  are  analyzed  and  evaluated  after  a  significant  amount  of  data  have 
been  gathered,  usually  a  one-day  to  a  two-week  sample.  In  contrast,  AVM  systems 
do  not  count  passengers  boarding  and  alighting  the  bus,  but  provide  bus  location 
and  schedule  adherence  information  for  real-time  monitoring  by  transit 
operations  staff.  In  the  late  1970' s,  automatic  passenger  counting  capability 
was  combined  with  vehicle  monitoring  capability  in  some  systems.  These  combined 
APC-AVM  applications  are  referred  to  as  integrated  systems. 

APC  system  components  can  be  divided  into  three  categories:  hardware,  software, 
and  personnel.  A  simplified  illustration  of  the  hardware  is  shown  in  Figure  1-1. 
The  glossary  of  terms,  included  as  Appendix  6.3,  is  a  useful  supplement  to  this 
diagram.  Nine  devices,  some  of  which  are  optional,  may  be  used  in  APC 
appl ications. 

To  gather  data  on  passenger  counts,  the  location  of  this  activity,  and  the  time 
of  this  activity,  seven  hardware  components  are  required.  Required  equipment 
incl udes : 

(1)  counting  sensors  to  detect  passenger  ons  and  offs; 

(2)  an  odometer  to  calculate  location  of  passenger  activity; 

(3)  a  clock  to  identify  the  time  events  occur  (arrival  at  stops,  dwell  time, 
etc.); 

(4)  a  microprocessing  unit  with  a  storage  device  to  accumulate  and  store  data 
on-board  the  bus; 

(5)  a  power  supply  to  convert,  condition,  and  filter  primary  bus  voltage  to  the 
data  collection  system  (Lawerence  and  Zumwalt.  1984); 

(6)  a  data  transfer  or  retrieval  device  to  transfer  the  data,  either  manually 
or  automatically,  from  the  bus  to  a  central,  stationary  computer;  and 

(7)  a  stationary  computer  for  data  processing  and  report  generation. 

Optional  hardware  includes: 

(1)    door  switches  to  register  door  opening   and  closing   activity   (used  to 
control  for  counting  when  bus  doors  are  closed);  and 
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Figure  1-1:  ARC  Hardware 
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(2)  signpost  hardware  (signposts,  modems,  and  antennae  or  receivers)  to  either 
augment  or  substitute  for  the  location  referencing  capability  of  odometer 
readings. 

To  produce  useful  reports,  other  information  must  be  merged  with  APC  data  during 
data  processing.  The  system  flowchart  in  Figure  1-2  displays  one  software 
developer's  (McEachern.  1981)  version  of  APC  data  processing;  it  is  presented  as 
an  illustration  of  the  data  typically  required  to  create  APC  data  files. 

Module  A  in  the  diagram  represents  the  initial  editing  and  labeling  of  APC  ("in- 
service")  data.  During  this  stage,  the  data  are  edited  for  i nconsi stenti es  in 
passenger  counts,  location  data,  and  APC  vehicle  assignment  information.  Data 
are  discarded  when  runs  or  parts  of  runs  do  not  conform  to  known  behavior  of  the 
transit  system  (ie:  too  many  passengers  carried  or  boarded  at  one  stop,  speed 
too  high  or  too  low  at  some  point,  distance  traveled  not  appropriate).  During 
this  stage,  the  bus,  route  and  run  numbers  of  the  APC  vehicle  assignments  are 
appended  to  the  APC  data. 

Module  B  edits  the  booking  information  which  identifies  the  bus  stop  location 
(bus  stop  number,  distance  from  previous  stop,  intersection  closest  to  the  stop, 
route,  and  any  other  information  needed  to  identify  the  bus  stop);  and  edits  the 
data  for  miscellaneous  data  such  as  deadhead  mileages.  Deadhead  mileage  is  the 
distance  traveled  by  the  bus  either  before  or  after  it  is  in  revenue  service. 

Module  C  edits  schedule  data,  rejecting  internal  contradictions  and  conflicts 
with  the  in-service  data  on  file.  This  is  the  first  opportunity  to  determine 
automatically  which  runs  did  not  take  place  or  were  truncated  because  of 
breakdowns.  This  module  matches  actual  performance  of  the  buses,  by  route  and 
run,  with  the  schedule  by  integrating  the  two  files.  This  process  is  required 
to  obtain  schedule  adherence  data  (McEachern.  1981).  In  addition  to  the  editing 
tasks  identified  in  Figure  1-2,  this  module  formats  and  generates  hard  copy 
reports  and  archives  the  data  for  possible  future  statistical  analysis  and  ad 
hoc  reports.  SPSS  packaged  software  is  most  frequently  used  for  report 
generation . 

Personnel  is  the  third  component  in  an  APC  system.  Transit  agencies  report  that 
at  least  one  full  time  person  is  needed  to  manage  the  APC  project.  Sometimes 
called  an  APC  technician,  this  person  is  responsible  for:  hardware  monitoring 
and  diagnostics;  coordinating  APC  vehicle  assignments;  devising  a  sampling 
plan;  running  the  programs;  entering  the  data  defined  above  (schedule,  bus  stop, 
vehicle  assignment,  etc.);  and  overseeing  general  operation  of  the  project. 
This  person  is  sometimes  responsible  for  data  transfer  as  well. 


1.2   Purpose  And  Objectives 

Interest  in  automated  data  collection  techniques  usually  stems  from  agencies' 
dissatisfaction  with  one  or  more  aspects  of  their  current  data  collection 
activity.  For  large  agencies,  the  relatively  high  costs  associated  with  manual 
methods  most  often  create  the  incentive  to  investigate  alternative  approaches, 
such  as  APCs.  For  smaller  agencies,  the  incentive  is  commonly  potential  access 
to  more  and  better  data  on  which  to  base  decisions. 

The  purpose  of  this  study  is  to  investigate  the  viability  of  APC  application  at 
Lane  Transit  District  in  response  to  Lane  Transit's  need  for  more  and  better 
ridership,  time,  and  system  performance  data.  In  addition  to  potential  uses  of 
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APC  data  by  planning,  scheduling,  marketing  and  management.  Lane  Transit  is 
interested  in  discovering  the  role  APCs  might  play  in  the  compilation  of  data 
for  Section  15  reports.  Section  15  reports  are  a  requirement  for  federal 
funding  through  the  Urban  Mass  Transportation  Administration's  (UMTA)  grant 
program.  This  requirement  mandates  the  collection  and  analysis  of  systemwide 
data  at  a  95%  confidence  level  with  ±10%  tolerance  (Bus  Transit  Monitoring 
Manual,  Vol.  1.  Mul ti systems .  1981).  Several  other  issues  of  particular  concern 
to  Lane  Transit  planners  include:  APC  hardware  reliability  and  data  accuracy; 
APC  benefits  and  costs;  APC  system  capabilities;  APC  system  complexity; 
potential  impacts  of  an  APC  system  on  current  operations;  and  maintenance  and 
personnel  requirements. 

Two  objectives  to  be  achieved  through  the  research  of  APC  systems  in  North 
America  are: 

(1)  to  determine  the  feasibility  of  APC  implementation  at  Lane  Transit  District 
based  on  state-of-the-art  APC  technology,  APC  benefits,  and  APC  costs;  and 

(2)  to  specify  the  system  components  which  will  satisfy  Lane  Transit's  data 
needs  (provided  that  APC  implementation  is  recommended  and  that  funding  for 
the  project  is  available). 


1.3  Approach 

The  information  contained  in  this  report  was  obtained  from  in-depth  review  of 
available  APC  documents  and  from  detailed  discussions  with  transit 
professionals,  vendors,  private  consultants,  and  public  agency  personnel 
involved  with  APC  use  or  study.  The  primary  sources  relied  upon  for  agency- 
specific  information  were  the  transit  professionals  most  closely  associated 
with  APC  use  at  their  agencies. 

The  research  of  APC  applications  consisted  of  five  phases: 

(1)  Identifying  APC  user  agencies; 

(2)  Surveying  known  APC  user  agencies; 

(3)  Visiting  two  sites  with  operational  APC  systems; 

(4)  Synthesizing  survey  responses  into  summaries  on  each  agency;  and 

(5)  Assessing  the  ef fecti vness ,   benefits,  costs,  and  special  considerations 
involved  in  APC  implementation. 

APC  user  agencies  were  identified  through  a  review  of  literature  on  automated 
data  collection  techniques.  This  information  was  supplemented  through 
conversations  with  transit  personnel  over  a  period  of  six  months.  The  agencies 
identified  as  APC  users  in  this  study  do  not  represent  the  totality  of  APC 
agencies.  APCs  are  used  in  Europe  as  well  as  in  North  America.  European  APC 
applications  are  not  discussed  in  this  study.  Two  other  APC  agencies  excluded 
from  this  analysis  are:  Quebec  City  and  Halifax,  Nova  Scotia.  APC  systems  in 
these  cities  were  not  researched  due  to  time  constraints  on  this  project.  For 
additional  information  on  current  North  American  APC  deployment,  the  reader  is 
advised  to  contact  the  transit  districts  in  these  cities.  Finally,  due  to  the 
surging  interest  in  APCs,  many  new  applications  of  APC  technology  will  likely  be 
seen  in  the  1980' s.  Past,  present,  and  future  APC  use  is  the  topic  of  discussion 
in  Chapter  Two. 
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Figure  1-2:  SYSTEM  FLOW  CHART  FOR  APC  DATA  PROCESSING 
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A  questionnaire  (included  as  Appendix  6.2)  was  developed  and  mailed  to  known  APC 
user  agencies.  The  questionnaires  were  used  as  the  basis  for  telephone 
Interviews  conducted  with  APC  personnel.  The  information  obtained  from  these 
interviews  was  summarized  and  the  summaries  were  sent  to  the  respective  agencies 
for  verification.  These  measures  were  taken  to  assure  the  accuracy  of  the 
information  and  to  give  the  agencies  the  opportunity  to  edit  and  expand  on  the 
summaries. 

To  better  understand  how  APC s  function  in  actual  applications,  visits  were  made 
to  Portland  TRIMET  and  Seattle  METRO  transit  agencies.  The  on-board  equipment 
was  demonstrated  by  representatives  of  these  two  agencies.  These  demonstrations 
were  a  valuable  contribution  to  this  research,  lending  conceptual  significance 
to  the  capabilities  of  the  hardware.  The  agency-specific  information  obtained 
from  these  site  visits  and  interviews  is  summarized  in  the  case  studies  in 
Chapter  Three. 

The  specific  applications  of  APC  technology  and  uses  of  APC  data  are  evaluated 
in  Chapter  Four.  This  chapter  presents  an  assessment  of  the  capabilities, 
effectiveness,  benefits,  costs,  and  special  considerations  involved  in  APC 
implementation. 

Finally,  in  Chapter  Five,  major  findings  are  summarized,  special  considerations 
are  outlined,  and  recommendations  are  made  regarding  APC  implementation  at  Lane 
Transit  District.  Although  this  recommendation  is  specific  to  this  agency,  the 
information  contained  in  this  chapter  will  benefit  other  agencies  contemplating 
the  implementation  or  expansion  of  automated  data  collection  systems. 
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Chapter  Two 
APC  Applications 


The  application  of  APC  techniques  in  North  America  is  limited  to  less  than 
twenty  agencies.  Experience  with  the  systems  is  also  limited  with  the  first  APC 
project  initiated  in  1977.  In  addition  to  the  APC  agencies  discussed  in  this 
study,  APCs  are  used  in:  Halifax,  Nova  Scotia;  Quebec  City;  and  Europe.  The 
application  of  APCs  in  these  places  was  not  investigated  in  this  study. 

In  the  search  for  APC  applications,  it  was  discovered  that  some  agencies 
experimented  with  APCs  in  the  1970' s  and  later  decided  to  discontinue  the 
projects.  These  pioneer  projects  (Early  APC  Experiments)  are  discussed  breifly 
for  purposes  of  comparison  to  fully  implemented  systems.  Through  this 
comparison,  the  importance  of  technological  advances  for  system  reliability  is 
evident. 

This  discussion  is  followed  by  an  introduction  to  the  agencies  currently  using, 
testing,  or  contemplating  use  of  APCs.  APC  applications  or  plans  at  these 
agencies  are  discussed  as  Implemented  Systems,  Demonstration  Projects,  and 
Potential  Future  Appl ications. 

2.1    Early  APC  Experiments 

Several  agencies  experimented  with  APCs  in  the  mid  and  late  1970's,  but  decided 
not  to  implement  APC  systems.  In  1977,  an  experimental  program  was  initiated  in 
Cincinnati,  Ohio  by  General  Motors.  In  1981,  the  agency  decided  not  to  proceed 
with  system  implementation,  and  the  project  was  moved  to  Windsor,  Ontario. 
General  Motors  subsequently  discontinued  the  APC  portion  of  its  operations. 

Another  pioneer  project  initiated  in  1977  and  later  discontinued,  the  APC 
program  in  Edmonton,  Alberta  entailed  prototype  testing  of  two  APC  units.  After 
testing,  the  program  was  discontinued  primarily  because  of  the  high  development 
and  implementation  costs. 

Minneapolis/St.  Paul  Metropolitan  Transit  Commission  (MTC)  and  the  California 
Department  of  Transportation  (CALTRANS)  experimented  with  APCs  in  1979.  MTC 
purchased  44  dual  beam  systems.  Due  to  contractual  differences  with  the 
manufacturer,  PRODATA,  and  the  resultant  non-delivery  of  on-board  storage 
units,  use  of  the  system  had  always  been  limited.  Since  there  was  no  mechanism 
for  on-board  storage,  the  drivers  recorded  count  readings  from  display  panels  at 
designated  points.  Consideration  was  given  to  having  drivers  call  in  counts 
over  the  radio,  but  the  agency  decided  this  would  create  too  much  interference 
for  the  drivers.  As  a  result,  MTC  does  not  use  APCs  as  part  of  its  on-going  data 
collection  program.  (Mul ti systems  Interim  Report.  1982) 

CALTRANS  also  experimented  with  APCs  in  1979.  A  demonstration  program  was 
initiated  with  six  small  transit  systems  to  determine  the  feasibility  of  APCs 
for  small  agencies.  Another  objective  was  to  determine  the  role  CALTRANS  might 
play  in  assisting  small  agencies  with  data  collection  processes.  Problems  arose 
in  coordinating  the  project  and  it  was  subsequently  abandoned. 
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2.2   Implemented  Systems 


At  least  thirteen  agencies  in  the  U.S.  and  Canada  have  implemented  or  are 
implementing  APC  systems.  Two  of  these  applications  are  integrated  systems  which 
combine  the  real-time  monitoring  capability  of  automatic  vehicle  monitoring 
systems  (AVM)  with  the  off-line  report  capability  of  automatic  passenger 
counting  systems  (APC).  Table  2.1  displays  the  characteristics  of  these 
agencies  according  to:  year  of  project  initiation;  total,  peak  and  base  fleet 
size;  route  structure;  service  area  population;  and  number  of  APC  buses. 

From  the  data  in  this  table,  it  is  evident  that  APCs  are  applied  to  a  variety  of 
transit  settings  and  that  property  characteristics  are  not  determining  factors 
in  the  application  of  APC  technology.  Five  small  agencies  (with  less  than  200 
buses  in  the  fleet)  and  ten  large  agencies  (greater  than  500  buses  in  the  fleet) 
have  had  some  experience  with  APCs.  Type  of  route  structure  also  varies  from 
complicated  (combined  radial,  grid,  and  feeder  trunk)  to  simple  (radial).  The 
service  area  populations  of  the  agencies  range  from  relatively  small  (less  than 
200,000)  to  very  large  (6  million).  Note  that  all  of  these  properties  are  peak- 
oriented  (have  high  peak/base  fleet  ratios).  The  use  of  APCs  for  systematic 
sampling  under  these  conditions  demonstrates  the  applicability  of  APCs  to  peak- 
oriented  transit  systems. 

Although  the  earliest  APC  implementations  were  at  relatively  large  agencies, 
small  agencies  began  APC  projects  within  two  years  of  the  first  applications  in 
Seattle  and  Ottawa.  The  year  of  project  initiation  is  not  a  valid  indicator  of 
APC  capability  or  age  since  many  of  the  earlier  systems  have  been  upgraded  over 
time.  These  upgrades  have  been  very  costly  for  some  agencies  because  extensive 
hardware  retrofits  and  software  modifications  have  been  required.  The  increased 
versatility  of  modern  systems  and  a  phased  approach  to  APC  implementation  help 
to  minimize  the  marginal  costs  of  upgrading  the  system  over  time.  Phased 
implementation  and  other  options  available  to  reduce  long-term  project  costs  are 
discussed  in  Chapter  Five. 

The  agencies  in  the  first  eleven  cities  listed  in  Table  2.1  have  operational  APC 
systems  providing  time,  location,  and  ridership  information  for  off-line 
reporting  and  analysis.  This  is  not  the  primary  objective  of  the  systems  in  Los 
Angeles  and  Toronto.  These  cities  use  integrated  APC-AVM  systems  with  screen- 
oriented  real-time  service  monitoring  as  the  principal  function.  In  Los 
Angeles,  real-time  monitoring  takes  precedence  over  off-line  reporting.  In 
Toronto,  the  APC  system  has  no  off-line  reporting  capability  and  all  data, 
including  passenger  counts,  are  displayed  on  screens.  Integrated  systems  are 
also  used  in  Hull,  Quebec  and  Rochester,  New  York  (Deibel  and  Zumwalt.  1984). 
The  APC-AVM  applications  in  Hull  and  Rochester  were  not  included  in  this 
research.  For  additional  information  on  integrated  systems,  the  reader  is 
advised  to  contact  the  transit  agencies  in  these  cities. 

Los  Angeles'  and  Toronto's  systems  illustrate  some  of  the  special  considerations 
involved  in  implementation  and  maintenance  of  integrated  systems.  Real-time 
monitoring  (AVM)  systems  are  designed  primarily  for  operations  control  and 
emergency  response.  For  this  reason,  AVM-APC  buses  are  assigned  continuously  to 
specific  routes.  In  order  to  consistently  monitor  the  system  in  this  manner,  a 
higher  percentage  of  the  fleet  must  be  AVM-equipped  than  is  required  for  sole 
APC  appl ication . 
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Table  2.1:    APC  User  Property  Characteristics 


Fleet  Service 

Began   Route  Population  tAPC 

APC       Total    Peak    Base      Structure  (millions)  Buses 


APC  Systems 

Seattle 

1978 

1069 

915 

450 

Radial 

1.3 

116 

Ottawa 

1978 

765 

710 

300 

Radial  ,  F.T.* 

.5 

66 

Kalamazoo 

1980 

54 

31 

23 

Radial 

.2 

20 

London 

1981 

160 

152 

90 

NA 

.2 

18 

Windsor 

1981 

92 

78 

39 

Modified  F.T. 

.2 

27 

Calgary 

1982 

683 

435 

155 

Mainline,  F.T 

.5 

5 

Portland 

1982 

631 

424 

228 

Radial ,  Grid, 

F 

T. 

1.0 

43 

Col umbus 

1982 

NA* 

294 

NA 

Radial,  F.T. 

.9 

20 

Chicago 

1983 

2275 

1950 

995 

Radial  ,  Grid 

3.7 

6 

Kitchener 

1985 

84 

70 

46 

Radial 

.2 

20 

Mi  ssi  ssauga 

1985 

172 

135 

70 

Radi al  ,  Grid , 

F 

T. 

.4 

30 

AVM-APC  Systems 

Toronto 

1978 

zuy  / 

1521 

"7  1  n 

/lO 

Gri  d 

2 . 1 

inn 

100 

Los  Angeles 

1980 

2500 

2100 

1300 

Radial ,  Grid, 

F 

T. 

6.0 

200 

APC  Demonstrations 

Washington 

1984 

2000 

1600 

1200 

Radial ,  Grid , 

F 

T. 

1.0 

9 

Denver 

1984 

745 

620 

326 

Radial ,  Grid 

NA 

10 

Notes: 

1.  F.T.=  Feeder  Trunk  Route  Structure 

2.  NA:  Information  not  available 
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2.3  Demonstration  Projects 

It  is  common  practice  for  agencies  to  conduct  demonstration  projects,  usually 
six  months  to  one  year  in  duration,  before  deciding  to  proceed  with  full  APC 
system  procurement.  These  demonstrations  are  often  part  of  a  phased  approach  to 
APC  acquisition  and  implementation.  In  some  cases,  the  services  of  a  system 
integrator  or  vendor  are  contracted  for  a  specified  time  period  to  conduct  on- 
site  testing  of  the  hardware  and/or  software.  At  some  agencies,  APC  units  were 
leased  during  the  demonstration  and  later  purchased.  Other  agencies  purchased 
the  equipment,  usually  a  small  number  of  units,  during  the  demonstration  phase 
and  later  expanded  the  systems. 

The  purposes  of  demonstration  projects  vary  with  the  requirements  of  the 
agencies.    Some  of  the  common  objectives  of  a  demonstration  project  are  to: 

(1)  perform  accuracy  and  reliability  testing  on  the  hardware; 

(2)  increase  familiarity  with  the  hardware  especially  with  installation  and 
maintenance  procedures  and  requirements; 

(3)  determine  the  feasibility  of  producing  some  or  all  of  the  hardware  and/or 
software  in-house  (City  of  Calgary  Report.  1983); 

(4)  minimize  the  long-term  costs  of  hardware  and  software  (Hardware  retrofits 
and  software  modifications  can  be  very  costly.  The  purchase  or  lease  of  a 
few  units  in  the  early  phases  of  the  project  reduces  the  amount  of 
retrofitting  that  may  be  needed  as  the  technology  progresses.  Also,  data 
processing  costs  are  significantly  reduced  with  sample  size.  Since  the 
software  will  be  developed  in  the  first  year,  a  smaller  sample  is  easier 
and  less  expensive  to  analyze  while  software  routines  are  perfected.); 

(5)  help  identify  long-term  hardware,  software,  and  personnel  needs;  and 

(6)  allow  for  formulation  of  internal  procedures  (OC-TRANSPO,  Ottawa). 


At  present,  at  least  two  agencies  are  conducting  demonstration  projects. 
Denver  Regional  Transportation  District  (RTD)  and  Washington  Metropolitan  Area 
Transit  Authority  (WMATA)  have  both  contracted  with  APC  vendors  to  conduct  on- 
site  testing  of  APCs.  Summaries  of  the  projects  at  these  agencies  are  presented 
here  as  sample  approaches  to  an  initial  APC  project. 
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2.4    Denver  Regional  Transportation  District  (RTD)  Demonstration  Project 

Interview  with  Jim  Oliver,  Manager  of  Schedules,  RTD,  Denver,  Colorado 

The  Denver  Regional  Transportation  District  (RTD)  proceeded  with  a  six  month  APC 
demonstration  project  in  November,  1984.  The  object  of  the  demonstration  is  to 
test  the  accuracy  and  reliability  of  the  hardware.  Two  firms  were  hired  to 
demonstrate  the  relative  effectiveness  of  different  types  of  hardware.  Pachena 
and  Urban  Transportation  Associates  (APC  system  suppliers)  have  each  installed 
APC  units  on  five  buses  and  10  signposts  along  routes.  The  equipment  from 
Pachena  was  purchased  by  RTD;  while  the  equipment  from  Urban  Transportation 
Associates  (UTA)  was  leased. 

The  objectives  of  the  demonstration  are: 

(1)  to  determine  if  there  are  statistically  significant  differences  between 
manual  and  APC  counts;  and 

(2)  to  determine  the  magnitude  of  the  differences  and  the  statistical 
reliability  of  APC  counts  under  the  range  of  loading,  passenger, 
environmental,  and  operating  conditions  normally  experienced  by  RTD  buses. 

The  tests  compare  APC  performance  to  manual  counts  as  well  as  comparing  the 
performance  of  one  system  to  the  other.  The  results  of  the  tests  are  not  yet 
complete  and  both  vendors  have  been  doing  a  certain  amount  of  "in  the  field" 
adjustments  to  improve  the  accuracy  of  their  respective  APC  units.  The 
estimated  date  of  completion  is  around  July,  1985. 

To  analyze  and  evaluate  the  test  data,  RTD  has  hired  a  consulting  firm,  IBI 
Group.  The  results  will  be  analyzed  in  terms  of  the  general  feasibility  of  APCs 
and  the  relative  effectiveness  of  the  two  systems  now  being  tested. 

RTD  hires  as  many  as  20  ride  checkers  during  the  year.  Retaining  good  ride 
checkers  is  a  problem  especially  since  the  checkers'  job  is  an  entry  level 
position  and  thus  has  a  high  turn-over.  For  this  reason,  APCs  are  viewed  as  a 
favorable  alternative  to  manual  counts. 


EVALUATION  OF  RTD'S  APC  SYSTEM 
COUNTING  SENSORS 

Treadle  mats,  manufactured  by  Pachena,  are  installed  on  five  buses.  Infrared 
beams  supplied  by  Urban  Transportation  Associates  are  installed  on  five  buses. 


ON-BOARD  MICROPROCESSOR 

Five  buses  contain  Pachena  microprocessors  and  five  contain  microprocessors 
supplied  by  Urban  Transportation  Associates. 
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LOCATION  REFERENCING  METHOD 


A  total  of  20  portable  signposts  are  used  to  reference  location  of  data  input. 
Ten  signposts  were  purchased  from  Pachena  and  ten  were  leased  from  Urban 
Transportation  Associates.  These  units  are  solar  powered  and  no  problems  have 
been  encountered  with  any  of  the  signposts.  The  signposts  are  located  as  close 
as  possible  to  specified  time  points  along  routes. 


DATA  STORAGE 

With  the  Pachena  units,  data  are  stored  in  solid  state  memory.  With  the  UTA 
units,  data  are  stored  on  cassette  tapes.  UTA  APC  data  are  later  processed  into 
reports.  The  data  obtained  from  the  Pachena  units  are  displayed  on  the  display 
pannel  of  a  portable  diagnostic  unit.  In  this  way,  cumulative  counts  from  the 
APC  units  are  compared  with  manual  counts  for  the  same  routes. 


DATA  TRANSFER 

No  data  transfer  or  processing  is  performed  with  the  Pachena  units.  In  the  UTA 
demonstration,  tapes  are  replaced  about  once  every  two  weeks  by  UTA  personnel. 


STATIONARY  CPU  AND  SOFTWARE 

Only  the  UTA  project  entails  data  processing  and  this  is  done  at  UTA  offices  on  a 
PRIME  mainframe  computer. 


REPORTS 

No  route  analysis  reports  are  required  of  the  vendors  as  part  of  the 
demonstration.  However,  UTA  will  provide  some  reports  in  order  to  further 
demonstrate  the  usefulness  of  the  system. 


APC  ACQUISITION  AND  FUNDING  SOURCE 

The  demonstration  projects  were  funded  100%  by  the  district.  Subsequent  APC 
acquisition,  if  recommended,  will  be  funded  80%  by  a  federal  capital  grant  and 
20%  by  the  agency.  An  RFP  process  was  used  to  select  the  system  integrators 
chosen  for  the  demonstrations. 


COSTS  OF  THE  APC  SYSTEM  (For  six  month  demonstrations) 

Urban  Transportation  Associates:  $42,500  (to  lease  hardware  and  perform 

limited  analysis  on  data) 

Pachena:  -  $27,700  (to  purchase,   install   and  test 

hardware) 

IBI  Consultants:  $50,000  (to  evaluate  test  results) 
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2.5  Washington  Metropolitan  Area  Transit  Authority  (WMATA) 
Demonstration  Project 

Interview  with  Jim  Robinson,  Systems  Engineer  and  APC  Project  Manager,  WMATA, 
Washington,  D.C.;  and  Tom  Kowalski,  Urban  Transportation  Associates 

WMATA  began  experimenting  with  APCs  in  1984  when  it  contracted  with  Urban 
Transportation  Associates  (UTA)  to  conduct  a  nine  month  test  installation  on 
nine  buses.  The  APC  units  were  leased  from  UTA  during  this  time.  Due  to 
organizational  restructuring  at  WMATA,  the  project  was  delayed  and  a  three  month 
extension  was  granted  to  the  project. 

This  demonstration  was  initiated  not  only  to  demonstrate  the  capabilities  of  the 
hardware  (including  the  capacity  to  collect  stop-level  data),  but  also  to  do 
some  extensive  analyses  and  to  make  recommendations.  Five  of  the  busiest  and 
most  challenging  routes  (having  a  high  level  of  interlining  and  operating  out  of 
more  than  one  garage)  were  chosen  for  the  test.  To  date,  route  analyses  have 
been  performed  on  all  but  one  of  the  routes  and  recommendations  have  been  made, 
on  the  basis  of  the  APC  data,  as  to  appropriate  service  levels  (route  changes, 
headway  alignments,  etc.)  on  the  four  lines  analyzed. 

The  benefits  and  costs  of  APCs  relative  to  the  present  manual  data  collection 
methods  are  of  primary  interest  to  the  agency.  WMATA  currently  employs  35  full- 
time  salaried  checkers  to  perform  maximum  load  checks  on  all  lines  three  times 
per  year  and  on/off  checks  every  two  years.  As  part  of  the  demonstration, 
counts  on  specified  routes  were  recorded  by  both  APCs  and  by  WMATA  staff  riding 
the  bus.  These  tests  of  the  on-board  equipment  comparing  APC  data  to  ride  check 
data  revealed  an  APC  accuracy  at  98-99%. 

Once  all  of  the  results  of  the  tests  are  presented,  the  agency  will  make  a 
determination  as  to  the  feasibilty  of  proceeding  with  system  procurement.  The 
systems  engineer  interviewed  wrote  the  specifications  for  the  APC 
demonstration.  He  is  convinced  that  the  technology  is  proven  and  believes  that 
APCs  are  a  valuable  tool  for  transit  agencies. 


EVALUATION  OF  WMATA 'S  APC  SYSTEM 
COUNTING  SENSORS 

WMATA  uses  infrared  beams  supplied  by  UTA.  Door  switches  are  used  to  record 
door  opening  and  closing  events.  The  sensing  devices  are  satisfactory  in  terms 
of  accuracy  and  reliability.  It  was  advised  that  the  maintenance  staff  be 
instructed  on  the  function  of  door  switches  to  avoid  accidental  damage  to  the 
equipment  during  non-APC  repair  work. 


ON-BOARD  MICROPROCESSOR 

The  microprocessor,  a  Motorola  6800  unit,  is  physically  located  inside  a  PDU 
(portable  data  unit).  An  interface  board  is  also  located  inside  the  PDU.  This 
device  interfaces  the  sensor  data  to  the  microprocessor  and  is  a  product  of  UTA 
and  General  Motors. 

The  PDU  contains  a  clock  (based  on  24  hour  time),  and  an  odometer.  Data  input  is 
activated  whenever  a  bus  enters  and  leaves  a  signpost  field  and  when  256  seconds 
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have  elapsed  since  the  last  record  was  written.  Each  time  a  record  is  written, 
data  are  time  and  distance  stamped.  In  this  way,  time  and  distance  between 
stops  are  calculated.    Reliability  and  accuracy  of  the  units  are  satisfactory. 


LOCATION  REFERENCING  METHOD 

Motorola  portable  signposts  are  used  to  reference  location  of  data  input.  The 
batteries  for  these  units  have  a  very  short  life  and  require  replacement  about 
once  every  two  weeks. 

According  to  the  engineer,  positioning  the  signposts  is  an  art.  He  suggested 
placing  one  signpost  at  the  maintenance  facility,  one  at  the  start  of  the  line, 
and  one  at  each  time  point  and  layover  point. 


DATA  STORAGE 

Data  are  stored  in  a  Datell  unit  on  cassette  tape. 


DATA  TRANSFER 

Data  are  retrieved  (tapes  replaced)  at  least  once  every  two  weeks  by  UTA 
personnel . 

STATIONARY  CPU  AND  SOFTWARE 

UTA  performs  a  complete  service  for  WMATA  including  data  transfer  and 
processing.  The  ARC  data  are  processed  on  UTA's  PRIME  computer  and  also  fed 
directly  into  WMATA' s  minischeduler  file  on  the  agency's  IBM  mainframe. 


REPORTS 

When  the  analyses  on  all  five  lines  are  complete,  UTA  will  have  provided  WMATA 
with  a  series  of  reports  on  each  line.  Based  on  these  reports,  UTA  will 
recommend  to  WMATA  appropriate  service  levels  for  these  lines. 

COSTS  OF  THE  APC  SYSTEM 

Demonstration  Project  costs:   $80,000  for  the  12  month  project 
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2.6   Potential  Future  Applications 


APC  use  has  expanded  rapidly  in  the  past  few  years  and  interest  in  automated 
data  collection  techniques  is  increasing  in  both  the  U.  S.  and  Canada.  Some  APC 
agencies  are  conducting  research  (see,  for  example,  Calgary  Summary)  prior  to 
expanding  their  present  systems  to  take  maximum  advantage  of  technological 
advances.  These  studies  are  usually  part  of  a  phased  approach  to  APC 
implementation. 

Some  agencies  with  no  prior  APC  experience  are  now  conducting  studies  for  their 
districts.  This  is  the  objective  of  a  study  soon  to  be  conducted  in  Madison, 
Wisconsin.  Madison  Metro  has  prepared  an  RFP  to  solicit  a  consulting  firm  to 
conduct  an  "Automated  Technology  Study".  The  purpose  of  the  study  is:  to 
evaluate  Madison  Metro's  current  radio  and  data  collection  systems;  to  assess 
available  radio  and  automated  data  collection  technology;  to  recommend  cost 
effective  improvements  to  Madison's  present  system;  and  to  provide  procurement 
assi  stance. 

In  addition  to  Madison,  APC  systems  are  being  considered  in  Jacksonville, 
Tuscon,  and  Atlanta  (Deibel  and  Zumwalt.  1984).  Studies  of  APC  technology  are 
now  either  underway  or  contemplated  in:  Vancouver,  B.C.;  Miami,  Florida;  New 
Jersey;  and  Fresno  County,  California. 
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Chapter  Three 


APC  Case  Studies 


The  application  of  APC  technology  in  North  America  today  lacks  uniformity  in 
design.  Technological  advances,  unique  data  requirements,  resource 
considerations,  environmental  factors,  and  changing  market  conditions  have 
influenced  trends  in  APC  deployment.  As  a  result,  application  has  been  limited 
and  highly  specialized  and  each  of  the  systems  now  in  use  is  unique  in  at  least 
one  essential  aspect. 

Changing  hardware  and  software  technology  has  contributed  to  the  specialized 
nature  of  APC  applications.  Earlier  systems  are  being  modified  to  add  new 
capabilities  as  technological  improvements  are  made,  data  needs  change,  and 
unanticipated  needs  are  realized.  The  system  components  also  vary  due  to  varying 
levels  of  resources.  Environmental  factors  such  as  rain  and  cold  affect  the 
reliability  of  certain  types  of  hardware,  further  contributing  to  specialized 
application.  In  addition,  some  hardware  manufacturers  and  software  developers 
have  left  the  market  and  new  ones  have  entered  over  the  years,  adding  to  the 
diversity  of  the  current  application  of  APCs. 

Due  to  this  lack  of  uniformity,  case  studies  provide  the  best  indication  of:  the 
status  of  existing  systems;  the  types  of  problems  encountered  by  user 
properties;  how  these  problems  have  been  addressed;  the  benefits  and  costs  of 
APCs;  and  the  different  approaches  to  APC  system  implementation.  The  case 
studies  presented  in  this  chapter  represent  all  but  a  few  of  the  APC  systems 
currently  in  use  in  North  America. 
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3.1    Seattle  METRO 


Interview  with  Tom  Friedman,  Senior  Transit  Planner,  METRO,  Seattle,  Washington 

METRO  began  implemention  of  an  APC  system  in  1978  when  Dynamic  Control 
Corporation  (DCC)  equipped  56  buses  with  treadle  sensor  mats  and  CPUs.  The 
system  consists  of  stairwell  mat  switches,  an  odometer,  an  internal  clock  for 
deriving  time  and  an  on-board  solid  state  storage  capability.  APCs  are 
installed  on  3  different  bus  types:  MAN  (articulated),  AMG  and  Flyer.  Some  of 
the  Flyers  and  articulated  buses  are  equipped  with  Li ft-U-Li fts. 

In  the  early  phases  of  the  project,  location  was  referenced  using  a  time 
matching  program.  This  method  assumes  that  the  bus  is  on  time  and  produces  a 
report  displaying  activity  by  locations  based  on  where  the  bus  was  "supposed  to 
be"  at  a  specific  point  in  time.  Since  buses  do  not  always  run  on  schedule,  more 
accurate  data  was  needed.  METRO  then  purchased  250  signposts,  manufactured  by 
AVM  Company,  and  installed  them  throughout  the  system.  The  major  criteria  for 
placement  of  signposts  was  the  assurance  that  each  APC  bus  receives  at  least  two 
signpost  signals  per  trip.  New  software  was  developed  to  process  the  additional 
data.  This  software  involves  the  use  of  a  computerized  mileage  template  to 
produce  a  geographical  representation  of  the  route  structure  and  automatically 
correlate  counts  to  specific  bus  stops. 

METRO  has  just  begun  to  process  the  APC  data  with  this  new  software  system.  At 
present,  about  50%  of  the  data  are  successfully  logged.  It  is  believed  that 
once  the  software  is  refined,  METRO  will  have  access  to  route  level  and  stop 
level  data  for  scheduling,  planning,  and  management  applications  for  use  both  in 
real-time  monitoring  and  off-line  analysis  and  reporting. 

In  1983,  METRO  contracted  with  Pachena,  Inc.  for  60  more  APC  units  which  brings 
the  total  to  116  or  12%  of  the  fleet.  METRO  planners  recommend  this  percentage 
as  a  guideline  for  properties.  These  systems  will  be  completely  installed  by 
the  summer  of  1985. 


EVALUATION  OF  METRO'S  APC  SYSTEM 
COUNTING  SENSORS 

The  DCC  counters  initially  purchased  by  METRO  in  1978  use  treadle  mats.  These 
mats  suffered  from  several  design  defects  including  water  infiltration  and 
bubbling.  DCC  is  no  longer  in  the  APC  business.  The  new  mats,  used  to  replace 
the  DCC  mats  and  supplied  by  Pachena  in  1983,  are  manufactured  by  London  Mat. 
These  mats  have  worked  well  so  far. 

Because  some  types  of  buses,  when  equipped  with  wheelchair  lifts,  have  only  one 
step  available  for  a  treadle  mat,  a  mat  must  be  placed  on  the  floor  level  at  the 
front  door.  This  has  not  been  a  problem  for  rear  door  sensors  which  are  placed 
on  the  steps.    No  wheelchair  counts  are  obtained  at  METRO  by  APCs. 

ON-BOARD  MICROPROCESSOR 

The  microprocessing  unit  is  located  on  a  partition  behind  the  driver's  seat. 
Unlike  the  DCC  units,  which  lost  stored  data  if  the  electrical  system  was 
disconnected,  the  Pachena  unit  contains  an  auxiliary  battery  which  prevents  the 
loss  of  stored  data. 
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Another  useful  function  of  the  Pachena  unit  is  the  capacity  to  record  front  and 
rear  door  activity  separately.  This  feature  allows  more  efficient  monitoring 
of  the  equipment  and  detection  of  failures  in  the  counting  sensors. 

Data  collection  is  on-going  as  opposed  to  "triggered"  by  certain  events.  The 
following  events  are  recorded: 

*  front  and  rear  door  opening 

*  front  and  rear  door  closing 

*  time  at  stops 

*  distance  (odometer  reading)  at  specific  intervals  to  compute 
speed 

*  signpost  code 

*  boardings  and  alightings 

*  dwell  time 

*  mat  switch  diagnostic  (every  12  hours,  a  record  is  generated  reporting 
the  number  of  times  a  switch  is  closed.  This  record  helps  to  determine 
when  a  mat  switch  is  failing.) 

 the  date,  device  number,  and  header  record  are  "stamped"  to  the  data. 


LOCATION  REFERENCING  METHOD 

METRO  initially  purchased  250  AVM  CO.  signposts  of  which  226  were  installed.  The 
AVM  signposts  transmit  coded  radio  signals  received  by  a  special  antenna  atop 
the  bus.  With  this  system,  a  bus  enters  and  exits  a  signpost  field  with  a  radius 
of  about  150',  and  the  CPU  records  the  signpost  field  entry  and  exit  codes.  The 
software  used  to  process  the  data  interpolates  between  the  enter  and  exit 
mileage  to  derive  location.  All  raw  data  locations  are  then  adjusted  by  a 
scaling  factor  to  produce  a  match  with  a  template  (contains  detailed  route 
information  including  schedule,  bus  stop,  and  time  point  data). 

One  option  suggested  by  METRO  planners  is  for  the  bus  driver  to  manually  enter 
location  data  by  pressing  a  reset  button  at  specific  intervals.  This  method 
could  be  used  in  place  of  signposts  at  a  considerable  cost  savings.  In  opting 
for  this  alternative,  two  considerations  should  be  recognized:  (1)  the  success 
of  this  technique  highly  depends  on  the  cooperation  and  reliability  of  the  bus 
drivers  especially  at  high  use  stops  where  drivers  are  most  likely  to  be 
distracted  or  preoccupied;  (2)  if  signposts  are  eventually  to  be  purchased,  the 
most  opportune  time  may  be  during  implementation  of  the  ARC  system  since  the 
costs  of  modifying  an  installed  system  for  signposts  are  high  and  there  may  be  a 
problem  finding  a  compatible  signpost  system  if  installation  of  signposts  is 
postponed.  Alternatively,  some  APC  systems  contain  an  external  connector  to 
enable  the  system  to  be  used  with  signposts  and  other  capabilities  that  may  be 
needed  in  the  future. 


DATA  STORAGE 

Data  are  stored  on-board  in  a  solid  state  record  storage  unit  with  a  capacity  up 
to  2000  stop  records. 
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DATA  TRANSFER 


Data  are  retrieved  with  portable  recording  units.  With  the  DCC  system,  data  are 
transferred  to  cassette  tape;  with  the  Pachena  system,  data  are  transferred  to  3 
1/2  inch  hard  disks.  Seven  or  eight  buses  can  be  fed  into  one  tape.  Data  are 
retrieved  twice  a  week  by  2  employees  who  perform  the  task  late  at  night  as  part 
of  their  regularly  scheduled  duties.    Transfer  takes  about  1  minute  per  bus. 


STATIONARY  CPU  AND  SOFTWARE 

METRO  uses  an  IBM  3033  mainframe  to  develop,  edit  and  run  the  APC  programs.  A 
PRIME  750  is  used  to  send  the  data  to  the  mainframe.  Competition  for  use  of  the 
system  has  been  a  problem  for  the  staff;  but  acquisition  of  a  new  computer  (VAX 
11/785)  for  various  functions  including  the  processing  of  APC  data  should  remedy 
thi s  problem. 

METRO  computer  services  division  is  developing  the  software  to  process  the  APC 
data.  The  software  is  written  in  RAMIS  II  and  FORTRAN,  and  involves  the  use  of 
templates  to  integrate  the  APC  data  with  a  geographical  representation  of  all 
routes  in  the  system.  The  geographical  part  of  the  system  is  called  TRANSGEO 
which  provides  the  capability  for  all  route  patterns  to  be  coded  onto  a  common 
base  map  (Census  DIME  file  map).  Bus  zones,  time  points,  and  signpost  locations 
are  also  coded  on  this  base  map.  In  addition,  INGRESS,  a  relational  data  base 
system,  will  be  used  to  retrieve  APC  information  on  the  new  VAX  computer. 


REPORTS 

At  present,  METRO  is  in  a  transitional  phase  of  APC  development  and  successfully 
logs  about  50%  of  the  data.  The  time-matching  software  produced  passenger  load 
profiles  by  time  of  day  in  tabular  and  graphic  format.  With  the  new  software, 
METRO  hopes  to  have  ready  access  to  ad  hoc  reports  as  well  as  reports  routinely 
used  by  planning,  scheduling,  and  management. 

In  addition,  the  ARCS  will  be  used  to:  (1)  assign  METRO'S  fleet  of  articulated 
buses  to  routes  where  they  will  be  the  most  effective;  (2)  compile  Section  15 
data;  (3)  plan  and  justify  route  changes;  and  (4)  create,  evaluate  and  adjust 
schedules  and  run  times. 


APC  IMPACTS  ON  CURRENT  OPERATIONS 

METRO  has  worked  extensively  with  operations  and  maintenance  staff  to  insure 
that  priority  is  given  to  APC  vehicle  assignments  and  maintenance  of  APC  buses. 
For  example,  special  parking  lanes  were  assigned  for  the  APC  buses.  Also, 
planning  sends  the  hostler  (the  person  who  assigns  vehicles  to  routes)  a 
calender  each  week  indicating  which  routes  require  sampling  and  which  APC  buses 
are  available.  The  hostler  makes  the  actual  assignments  based  on  this  calender. 

Cooperation  between  planning  and  maintenance  is  another  important  component  of  a 
successful  APC  program.  At  METRO,  the  planning  staff  notifies  maintenance  when 
they  suspect  from  the  data  that  there  is  a  hardware  problem. 

METRO  continues  to  use  8  full-time  salaried  point  checkers  to  manually  collect 
data.    It  is  felt  that  the  APC  system  has  reduced  the  need  to  hire  additional 
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checkers  even  though  the  service  level  has  grown  almost  50%  since  the  APC 
project  was  initiated. 


APC  ACQUISITION  AND  FUNDING  SOURCE 

METRO  used  a  bid  process  to  select  a  supplier  of  the  APC  system.  In  the  1983 
purchase  of  APCs,  Pachena,  Red  Pine  Instruments,  and  Dynamic  Controls  were  the  3 
companies  to  respond.  Pachena,  the  lowest  bidder,  was  selected  as  they  agreed 
to  meet  all  specifications  including  a  full  2  year  warranty.  The  project  was 
funded  by  an  UMTA  Section  3  capital  grant. 

COSTS  OF  THE  APC  SYSTEM 

The  costs  below  are  for  the  AVM  signposts  initially  purchased  by  METRO  and  for 
the  new  Pachena  system. 

CAPITAL  COSTS 


Counting  Sensors  (mats): 
Microprocessor: 
Instal lation : 

Data  Retrieval  Unit: 
System  Test/display  Unit: 
Signposts : 

Signpost  Installation: 
Signpost  receiver: 
Signpost  receiving  antenna: 
Software  Development: 


$  1200  to  $1700  per  bus  including  wiring 
$  1500  per  bus  including  wiring 

24  person  hours  per  bus  to  install 
mats  and  microprocessor 
$  4000  to  $5000  per  unit 
$  1500  per  unit 
$   300  per  unit 

2   person  hours  per  unit 
$  1000  per  unit 
$   200  per  bus 

2  person  years  to  date 


*OPERATING  COSTS  (Based  on  the  original  56  APC  units) 

Hardware  Maintenance:  .75  FTE 

Data  Analysi s:  1  FTE 

*Data  processing  costs  and  costs  of  replacement  parts  are  not  included. 
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3.2.  Ottawa -Carleton  Regional  Transit  Commission  (OC  TRANSPO) 

Interview  with  Joel  Koffman,  Systems  Planning  Supervisor,  Ottawa-Carl eton 
Regional  Transit  Commission  (OC  TRANSPO),  Ottawa,  Ontario 


Initially  implemented  in  early  1978,  OC  TRANSPO' s  APC  system  is  report-oriented 
for  use  in  planning,  scheduling,  and  management.  Of  a  total  66  APC-equipped 
buses,  54  contain  Prodata  lightheads  and  12  contain  Red  Pine  lightheads.  Red 
Pine,  located  in  Ontario,  manufactured  the  microprocessing  units  for  the  66 
buses.  Of  the  66  APC  buses,  about  60  produce  good  data  on  any  given  day.  Hardware 
maintenance  (both  APC  and  non-APC  related)  and  operational  procedures  such  as 
problems  associated  with  data  transfer  account  for  data  loss  on  the  remaining 
buses . 

Overall,  TRANSPO  is  enthusiastic  about  the  potential  and  capabilities  of  APCs. 
The  planners  are  satisfied  with  the  accuracy  of  the  data;  and  they  would 
definitely  repeat  their  APC  experience.  TRANSPO  views  APCs  as  cost-effective  for 
two  reasons: 

(1)  APCs  replaced  7  of  8  salaried  ride  checkers.    This  was  accomplished  by 
attrition  and  alternate  job  placement. 

(2)  Every  decision  based  on  APC  data  to  redirect  service  deployment  improves 
operational  efficiency  and  increases  productivity. 

Currently  OC  TRANSPO  is  upgrading  the  existing  APC  software  and  adding  extra 
time  utilization  descriptive  records  to  the  on-bus  unit  output.  These 
modifications  will  be  completed  by  March,  1986.  Although  they  have  not  ruled  out 
the  possibility  of  converting  to  an  AVM  system  in  the  future,  they  believe  the 
cost  of  equipping  the  total  fleet  with  AVM  hardware  will  be  a  major 
consideration. 

EVALUATION  OF  OC  TRANSPO 'S  APC  SYSTEM 

This  evaluation  applies  to  the  current  system  which  will  be  fully  upgraded  and 
operational  by  March,  1986. 


COUNTING  SENSORS 

OC  TRANSPO  uses  Prodata  and  Red  Pine  infrared  counting  sensors.  Subsequent  to 
TRANSPO' s  initial  acquisition  in  1978,  Prodata  stopped  making  the  sensors.  Red 
Pine  then  began  to  manufacture  the  light  heads  in  order  to  facilitate  sales  of 
its  microprocessors.  Red  Pine  equipped  12  additional  buses  with  counting  sensors 
and  microprocessors  in  1982.  These  newer  units  were  installed  on  articulated 
buses  only.  To  accomodate  the  three  doors  on  the  articulated  buses,  a  total  of 
five  passenger  streams  (or  ten  lightheads)  per  bus  were  required. 

TRANSPO  is  very  pleased  with  the  sensors  in  terms  of  unit  reliability.  This 
planner  contends  that  any  errors  in  counting  will  have  little  impact  on  overall 
results  as  long  as  the  errors  are  made  consistently  throughout  the  sample. 
Although  high  use  stops  are  perceived  to  introduce  some  additional  error,  this 
is  not  considered  to  be  consequential  and  is  not  of  major  concern  at  TRANSPO. 
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ON-BOARD  MICROPROCESSOR 


The  microprocessors,  or  Passenger  Counting  Units  (PCUs),  are  made  by  Red  Pine. 
As  a  result  of  advances  in  technology,  TRANSPO  ended  up  with  two  somewhat 
different  types  of  PCUs: 

(1)  The  54  microprocessors  initially  purchased  at  TRANSPO  have  only  4K  byte 
storage  capacity  while  the  12  newer  units  store  up  to  12K  bytes; 

(2)  The  newer  units  record  dwell  time  and  the  older  units  do  not. 

The  data  recorded  by  the  PCUs  are:  passenger  boardings  and  alightings,  relative- 
time  stamps  between  stops,  odometer  readings,  and  dwell  time  (on  the  12  newer 
units).  Relative-time  was  prefered  over  real-time  due  to  the  fact  that  to  obtain 
real  time  stamps,  the  clocks  on  all  APC  buses  would  need  to  be  synchronized  on 
occasion.    Relative  time  stamps  avoid  the  need  for  this  task. 

Data  accumulated  in  the  PCU  are  written  to  record  at  every  odometer  "click". 
Movement  of  the  bus  for  fifty  feet  after  stopping  causes  an  odometer  click 
provided  that  a  significant  event  (passenger  counts  or  idle  time  greater  than 
one  minute)  has  occured  when  the  bus  was  stationary. 

The  PCU  also  flags  memory  space  overflow  when  the  storage  capacity  for  time  or 
distance  is  exceeded.  The  PCU  accumulates  distance  data  up  to  2.6  miles  and 
then  resets  the  odometer  to  zero.  Similarly,  the  clock  is  reset  to  zero  after 
one  hour  has  passed.    In  each  instance,  a  record  is  written  to  signal  the  event. 

The  original  54  units  were  placed  on  the  floor  behind  the  driver's  seat.  There 
has  been  a  problem  with  the  plug  connecting  this  "black  box"  to  the  power  source 
being  pulled  out.  To  avoid  this  problem,  the  new  units  were  placed  behind  and 
above  the  driver's  seat. 


LOCATION  REFERENCING  METHOD 

The  location  referencing  method  employed  at  TRANSPO  is  the  same  method  used  at 
TRIMET  in  Portland.  Location  data  is  derived  using  a  computer  generated 
comparison  of  APC  odometer  readings  with  trip  distance  files.  This  method  is  not 
considered  satisfactory  due  to  the  loss  of  an  entire  day's  data  if  a  bus 
deviates  even  slightly  from  its  scheduled  route. 

To  prevent  the  loss  of  data  due  to  route  deviation,  OC  TRANSPO  plans  to  install 
32  signposts  and  signpost  receivers  (on  all  66  buses)  and  to  modify  existing 
PCUs  (Passenger  Counting  Units)  to  process  the  signals.  The  signposts  have  been 
designed  by  Toronto  Transit  Commission.  OC  TRANSPO  will  begin  by  purchasing  and 
field  testing  three  signposts  and  receivers  for  6  months  in  order  to  gain 
experience  with  signpost  technology. 

Signposts  will  be  used  to  obtain  route-level  and  route  segment-level  data.  The 
system  will  have  the  capability  to  provide  stop-level  data  as  well  should  this 
level  of  disaggregation  be  desired  in  the  future.  OC  TRANSPO  intends  to  install 
the  signposts  to  obtain  at  least  one  signpost  reading  on  each  round  trip  for 
every  route  in  the  system.  The  new  system  will  thus  have  the  capacity  to  accept 
with  confidence  data  on  a  trip  rather  than  a  run  basis.  Calculations  based  on 
this  reasoning  resulted  in  a  perceived  need  for  32  signposts  in  order  to  cover 
all  120  OC  TRANSPO  routes. 
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DATA  STORAGE 


The  PCU  on-board  the  bus  uses  a  solid  state  memory  device  for  storing  data.  The 
storage  capacities  of  the  two  types  of  PCUs  are  4K  byte  and  12K  byte. 

On-board  storage  of  more  than  a  day's  worth  of  data  is  not  desired  at  TRANSPO 
since  it  increases  the  risk  of  data  loss  and  delays  identification  of  equipment 
problems.  This  becomes  particularly  important  if  the  problem  occurs  early  during 
the  first  day  of  storage.  For  reasons  discussed  below,  TRANSPO  has  switched  to 
radio-link  data  transfer. 


DATA  TRANSFER 

Until  January,  1985,  TRANSPO  used  portable  recording  units  requiring  manual 
operation  to  transfer  the  data  onto  diskettes.  These  units  were  used  for 
diagnostics  as  well  as  data  transfer.  The  transfer  was  performed  by  security 
guards  at  the  end  of  each  day.  The  security  guard  picked  up  the  diskette  unit  and 
a  blank  diskette  each  night  and  took  these  to  the  APC  buses  which  were  lined  up 
in  a  specified  area.  The  unit  was  "plugged  in"  to  the  PCU  and  a  light  signaled 
when  the  transfer  was  complete.  After  all  the  data  were  retrieved,  a  microchip 
in  the  diskette  unit  sent  a  signal  to  the  CPU  to  clear  memory  and  begin  a  new 
counting  day.  Data  transfer  took  about  20  seconds  per  bus. 

OC  TRANSPO  found  manual  transfer  unreliable.  Very  often  APC  data  could  not  be 
retrieved  because  the  bus  was  on  a  hoist,  a  substitute  guard  was  on  duty, 
security  took  precedence  over  APCs,  etc.  The  guards  eventually  requested 
TRANSPO  to  hire  a  full  time  person  to  retrieve  the  data. 

In  response  to  this  problem,  TRANSPO  switched  to  an  automated  radio  transmission 
link  via  a  special  radio  channel.  Red  Pine  designed  a  modem  which  interfaces  the 
microprocessor  to  the  radio.  OC  TRANSPO  data  processing  staff  developed  the 
software  that  controls  the  radio  transfer  link.  The  property  tested  one  unit  for 
4  months  and  subsequently  retrofitted  the  entire  APC  fleet.  It  took  several 
months  to  fine  tune  the  system.  It  is  now  fully  operational  and  data  are  being 
extracted  reliably  every  evening. 

Transfer  takes  place  as  follows:  At  10:00  each  night,  a  retrieval  program  in 
the  VAX  stationary  computer  comes  on  line  and  signals  bus  #1  to  respond  if  it  is 
in  the  garage.  Once  a  bus  has  been  stationary  for  30  minutes,  the  radio 
automatically  switches  to  a  special  channel.  The  radio  transfer  is  interactive. 
If  a  signal  is  too  weak  to  be  received,  the  VAX  program  requests  a  repeat  signal. 
Once  all  of  the  data  have  been  retrieved,  the  program  signals  bus  #2  and  so  on. 
The  data  are  stored  in  VAX  files  for  processing.  The  software  real-time  stamps 
the  data  directly  after  they  are  transferred. 

STATIONARY  CPU  AND  SOFTWARE 

In  the  early  stages  of  APC  development,  TRANSPO  leased  time  on  Group  Five's  (a 
consulting  firm  in  Ontario)  PRIME  computer  to  process  APC  data.  In  1980, 
TRANSPO  purchased  a  VAX  11/780  computer. 

The  software  to  process  the  APC  data  was  initially  developed  by  Group  Five 
Consultants.  This  firm  continued  to  work  with  TRANSPO  in  both  minor  software 
enhancement  and  software  maintenance  until  1983.  At  this  point,  OC  TRANSPO  made 
the  decision  to  maintain  the  software  in-house. 
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The  planners  see  the  main  problem  with  processing  the  APC  data  as  a  data  base 
management  problem.  The  3  software  functions  essential  for  processing  the  APC 
data  are:  (1)  raw  data  validation  and  matching  to  prescribed  schedules;  (2) 
organizing,  sorting  and  storing  data  files;  and  (3)  formatting  the  output  in 
such  a  way  so  that  reports  are  generated  which  suit  the  needs  of  the  individual 
users.  TRANSPO  planners  believe  the  SPSS  package  can  be  used  to  label  and  format 
reports. 

A  total  rewrite  of  the  software  is  currently  being  performed  by  Systemware  (see 
TRANSPO  ASSESSMENT  AND  SUGGESTIONS).  It  is  expected  that,  with  this  software, 
all  of  the  processing  required  to  validate  and  match  data  will  be  automatically 
done  during  the  night. 

In  the  morning,  they  expect  to  have  access  to  validated  data  which  have  been 
correlated  with  route  profiles.    In  addition,  two  reports  should  be  available: 

(1)  A  report  identifying  bus  runs  on  which  data  were  successfully  retrieved 
during  the  night;  and 

(2)  a  diagnostic   report   pinpointing   problems  with   either   the  hardware  or 
schedul e  prof 1 1 es . 

One  of  the  specifications  In  the  RFP  was  that  the  software  become  the  property 
of  the  province  of  Ontario  for  use  by  other  properties. 


REPORTS 

Schedule  data  from  a  mini -scheduler  software  package  by  SAGE  (a  Toronto  software 
firm)  and  data  from  a  bus  stop  file  (created  by  TRANSPO)  are  automatically 
correlated  with  the  APC  data  to  produce  reports.  The  software  by  SAGE  is  an 
Interactive  schedule  writing  system. 

With  the  current  software,  OC  TRANSPO  attempts  to  capture  every  run  once  during 
a  sign-up  (there  are  four  sIgn-ups  per  year).  The  property  has  yet  to  capture 
all  scheduled  runs  once  in  a  sign-up  period.  Software  does  exist  to  crudely 
factor  data  to  represent  total  scheduled  service. 

Another  problem  encountered  at  TRANSPO  is  that  the  software  is  designed  so  that 
ad  hoc  reports  can  be  produced  only  on  a  semi-manual  basis  which  requires  much 
human  effort.  Also,  the  data  base  can  be  accessed  only  at  the  end  of  a  sign-up 
when  a  quarter  is  complete. 

APC  IMPACTS  ON  CURRENT  OPERATIONS 

OC  TRANSPO  replaced  7  of  8  salaried  ride  checkers  either  through  attrition  or 
alternate  job  placement  when  APCs  were  installed.  The  planner  believes  the  APC 
counts  are  more  accurate  than  the  checker  counts  due  mainly  to  the  fact  that  the 
job  of  checking  is  boring,  routinized  and  unstimul ati ng  and,  thus,  checkers  are 
likely  to  be  less  concerned  about  error.  Also,  the  volume  of  data  collected  by 
APCs  is  much  greater  than  could  be  obtained  through  former  manual  methods. 

For  operations,  the  impacts  were  numerous.  Some  of  the  most  important 
consldeartlons  were: 
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(1)  the  initial  reassignment  of  parking  lanes  for  APC  equipped  buses; 

(2)  the  cooperation  and  coordination  of  the  bus  starter  who  makes  driver-bus 
assignments; 

(3)  the  cooperation  of  garage  staff  (electrical  and  body  shop)  to  perform 
initial  installation  of  equipment;  and 

(4)  the    cooperation    of    the    garage    electrical    staff    to    assist    in  APC 
maintenance. 

Bus  drivers  are  not  involved  in  any  way  with  the  APCs. 

For  planning,  APCs  have  supplied  access  to  more  and  better  quality  data.  They 
now  have  more  complete  information  on  which  to  base  decisions. 

OC  TRANSPO  integrated  the  APCs  gradually  throughout  the  entire  property  so  that 
each  individual  division  "owned"  its  own  piece  of  the  project  in  terms  of 
responsibilities.  This  created  an  amiable  and  cooperative  atmosphere  which 
lessened  the  impact  of  the  APC  project.  For  example,  before  an  APC  bus  is  put 
back  on  the  road  after  being  in  the  shop  for  repairs,  an  electronics  specialist 
checks  over  the  entire  APC  system  to  be  sure  it  was  not  accidently  damaged. 
There  is  considerable  cooperation  between  planning  and  the  electrical  shop 
regarding  APC  maintenance. 


TRANSPO  ASSESSMENT  AND  SUGGESTIONS 

In  early  1984,  TRANSPO  made  a  careful  assessment  of  its  APC  system  and 
identified  the  following  limitations  restricting  the  usefulness  of  the  APC 
system: 

(1)  Location  data  is  inadequate; 

(2)  On-board  microprocessors  have  different  capabilities; 

(3)  Idle  time,  stop  time,  and  traffic  congestion  data  are  not  available  as 
output  from  the  on-bus  microprocessor; 

(4)  Data  transfer  method  is  unreliable; 

(5)  The  software  is  designed  to  allow  only  one  sample  of  each  bus  run  to  be 
recorded  during  each  3  month  booking  period; 

(6)  The  software  will  allow  analysis  reports  on  only  an  entire  booking  period 
(once  every  3  months); 

(7)  The  software  will  not  produce  ad-hoc  reports  between  quarterly  analysis, 
except  on  a  semi -manual  basis.  The  ad-hoc  report  that  is  available  is  very 
1 i mi  ted  in  scope; 

(8)  The  present  system  of  inputting  missing  bus  runs  is  time  consuming  both  in 
human  and  computer  processing; 

(9)  The  formatting  of  reports  does  not  accommodate  the  needs  of  the  users  of 
the  data; 

(10)  The  procedure  now  used  to  create  the  run  profiles  with  which  the  APC  data 
are  matched  is  cumbersome  and  rigid; 

In  response  to  #1  through  #4  above,  TRANSPO  has  contracted  with  Red  Pine  to 
upgrade  the  hardware;  to  make  the  system  uniform;  to  modify  the  microprocessors 
to  record  signpost  data  and  to  analyze  time  utilization  along  each  trip;  and  to 
design  and  manufacture  a  modem  for  use  on-board  the  bus  to  allow  radio  transfer 
of  the  data.  The  installation  of  thirty-two  signposts,  manufactured  by 
Electrocom  (a  Toronto  firm)  and  designed  by  Toronto  Transit  Commission,  is 
planned.  At  present,  prototype  testing  is  under  way  with  three  signposts  and 
receiver  units  utilized  with  the  new  up-graded  passenger  counting  units. 
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Conversion  from  a  manual  data  transfer  method  to  radio-link  transfer  is  complete 
with  the  necessary  hardware  installed  on  all  66  buses.  KVA  Communications,  a 
radio  network  consulting  firm  in  Ontario,  assisted  with  the  overall  design  of 
the  radio  transfer. 

To  remedy  the  software  problems,  TRANSPO  recently  awarded  Systemware  a  contract 
to  design,  develop,  document,  and  implement  applications  software  to  process  APC 
data  and  to  produce  reports.  Development  of  this  software  will  cost 
approximately  $250,000  (in  Canadian  dollars)  and  will  take  about  18  months  to 
complete  (scheduled  completion  date  is  March,  1986). 

Based  on  seven  years  of  experience  with  APCs,  the  property  suggests  the 
following  precautionary  measures  to  cut  long-term  costs  of  APCs  and  to  smooth 
APC  implementation: 

(1)  The  property  should  clearly  identify  its  data  needs  from  the  outset  (ie: 
desired  level  of  accuracy,  type  and  amount  of  data  required,  etc.). 

(2)  Strong  support  and  directive  from  transit  management  for  APCs  from  the 
project's  inception  will  facilitate  acceptance  and  integration  of  APCs. 

(3)  A  6  month  pilot  project  is  advised  using  about  two  prototypes  leased  or 
borrowed  from  a  supplier  or  another  property.  A  pilot  project  serves  the 
following  functions: 

(a)  affords  the  property  the  chance  to  become  familiar  with  the  APC 
system; 

(b)  allows  for  anticipation  of  future  hardware  needs; 

(c)  provides  an  indication  of  software  needs;  and 

(d)  allows  for  formulation  of  internal  procedures. 

(4)  A  thorough  understanding  of  the  hardware  by  planning  division  personnel  is 
critical  for  the  success  of  the  APC  project;  and  a  large  commitment  of  time 
and  dedication  is  required  on  the  part  of  staff  directly  involved  with  the 
APC  system. 


APC  ACQUISITION  AND  FUNDING  SOURCE 

Red  Pine  was  automatically  awarded  the  contract  to  upgrade  the  hardware  since 
this  company  was  the  original  supplier. 

TRANSPO  used  an  RFP  process  to  purchase  the  software.  Systemware  won  the 
software  contract  because  the  company  displayed  the  most  thorough  understanding 
of  the  specifications  and  presented  the  most  viable  options  for  meeting  them. 
Systemware' s  fee  was  approximately  $250,000. 

The  APC  project  has  been  and  continues  to  be  funded  75%  through  capital  funds 
from  the  province  of  Ontario.  The  property  provides  the  remaining  25%  of  the 
funds. 
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COSTS  OF  THE  APC  SYSTEM 


Prices  are  based  on  the  cost  of  the  12  units  purchased  in  1982.  Figures  are 
quoted  in  Canadian  dollars. 


CAPITAL  COSTS 

Counting  Sensors  (optics): 

Microprocessor: 

Instal 1 ation : 

Portable  Transfer  Device: 

Signpost  Transmitter: 

Signpost  Transmitter  Installation: 

Signpost  Receiver: 

Signpost  Receiver  Installation: 

Software  Development 

PCU  modifications: 

Conversion  To  Automated  Radio  Transmi 


$    400  per  passenger  counting  stream 

$  3,300-3500  per  bus 

2  person  days/bus 

$  5,000  per  unit 

$  1,200  per  unit 

not  yet  determined 

$    300  per  unit 

not  yet  determined 

$250,000   SW  development  by  Systemware 
$         300    per    bus    (for    new  upgraded 
system) 
ssion: 

$  25,000  for  pilot  project 

$  30,000  to  retrofit  66  buses  with  modem 

(incl .  instln. ) 


OPERATING  COSTS 


Hardware  Maintenance; 

Data  Processing: 
Data  Analysi  s: 


$  22,000  (Red  Pine  charges,  replacement 
parts,  and  1  FTE) 

1  FTE 

2  FTE  (users  and  report  generation) 
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3.3  Kalamazoo  Metro 


Interviews  with  Bill  Schomisch,  Director,  Kalamazoo  Metro  Transit,  Kalamazoo, 
Michigan;  and  Chuck  Richard,  Project  Manager,  Michigan  Department  of 
Transportation  (MOOT) 

Metro's  APC  system  was  first  implemented  in  1980  when  the  Michigan  Department  of 
Transprtation  (MOOT)  and  Metro  contracted  with  General  Motors  Transportation 
Systems  Center  (GMTSC)  for  the  purchase  and  demonstration  of  20  APC  units.  The 
project,  funded  100%  by  a  state  demonstration  and  development  grant,  was 
implemented  in  order  to  examine  the  applicability  of  APC  techniques  in  the 
service  monitoring  programs  of  small  transit  properties  in  the  state. 

Although  Metro  is  the  only  Michigan  property  to  use  APCs  at  the  present  time, 
the  districts  of  Ann  Arbor  and  Grand  Rapids  are  now  planning  to  conduct 
demonstration  projects  as  a  result  of  the  perceived  success  of  Metro's  APCs. 
The  recently  developed  RFP  for  Grand  Rapids  specifies  a  6  month  demonstration 
using  2  APC  buses  on  one  route.    Ann  Arbor  is  planning  a  similar  approach. 

Metro's  APCs  were  completely  installed  in  1982.  Subsequent  to  the  initial 
installation.  General  Motors  underwent  an  organizational  restructuring  and 
decided  to  drop  the  APC  program.  Two  of  GM's  APC  staff  persons  left  GM  and 
formed  Urban  Transportation  Associates  (UTA),  a  consulting  firm  in  Cincinnati. 
UTA  proceeded  to  service  Metro's  APCs. 

Metro  is  a  city  Department  of  Transportation  consisting  of  three  divisions: 
Administration,  Operations,  and  Maintenance.  The  report  oriented  APC  system  is 
primarily  used  and  operated  by  Administration  to  serve  planning  functions. 
Initially,  the  APC  data  provided  information  on  schedule  adherence,  route 
analyses,  and  productivity  studies.  They  now  include  information  for  ridership 
reports  as  well.  The  information  is  used  to:  evaluate  route  performance;  make 
schedule  adjustments;  improve  system  performance;  evaluate  alternative 
operating  methods;  and  provide  data  for  UMTA  Section  15  reports. 

In  addition  to  these  reports,  APC  data  has  served  two  critical  functions  at 
Metro: 

(1)  Prior  to  acquiring  APCs,  Metro  did  not  use  bus  stops;  patrons  signaled  for 
the  bus.    Metro  used  APCs  to  locate  bus  stops. 

(2)  In  1982,  there  was  a  $600,000  budget  cut  at  Metro.  The  use  of  APC  data 
facilitated  route  restructuring  and  service  cutbacks  which,  according  to 
those  interviewed,  were  responsible  for  subsequent  increased  productivity. 

These  functions,  along  with  elimination  of  ride  checks,  substantiate  the  cost 
effectiveness  of  APCs  for  this  property.  These  benefits  cannot  long  justify  the 
monthly  expense  of  UTA's  services,  however.  For  a  fee  of  $2,700  per  month,  UTA 
provides:  data  processing;  software  design  and  development;  software  and 
hardware  modifications  needed  to  add  report-generating  capabilities;  some 
hardware  maintenance;  and  all  final  reports.  Metro's  goal  is  to  become  fully 
independent  of  UTA  as  soon  as  it  purchases  an  IBM  PC  AT,  and  UTA  modifies  the 
software  for  use  with  this  computer. 

Overall,  Metro  and  MOOT  are  enthusiastic  about  the  success  of  the  APC  project, 
and  the  MDOT  plans  to  repeat  the  APC  experience  at  other  properties  in  the 
state. 
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EVALUATION  OF  METRO'S  APC  SYSTEM 


COUNTING  SENSORS 

Twenty  buses,  37%  of  the  fleet,  are  equipped  with  Honeywell  dual  beam  infrared 
sensors.  As  is  often  the  case  with  infrared  beams  (I-R  beams),  adjustments  were 
required  in  positioning  the  sensors  on-board  the  bus.  In  Metro's  case,  the 
lightheads  were  moved  closer  to  the  driver  inside  the  fire  extinqui shing  area  by 
the  glove  compartment  so  that  counting  occurs  on  the  top  step.  This  move  was 
necessitated  by  interference  from  hands  holding  on  to  the  handrail  and  blocking 
counts. 

Metro  estimates  that,  as  a  result  of  these  adjustments,  accuracy  improved  from  a 
previous  80-85%  to  the  current  95-97%.  Metro  reports  that,  in  some  instances, 
accuracy  is  now  99%.  Also,  the  number  of  people  boarding  or  alighting  at  any  one 
stop  has  never  been  a  problem  at  Metro. 

Metro  is  satisfied  with  the  reliability  of  the  sensors  as  well.  Although 
maintenance  of  the  sensors  has  not  been  a  problem  at  Metro,  repair  work  on  the 
wheelchair  lifts  has  indirectly  created  problems  for  the  APCs.  The  wheelchair 
lifts  have  required  considerable  repair  and,  in  the  process  of  fixing  them,  APC 
wires  and  switches  have  been  damaged.  Due  to  minor  hardware  problems  as  well  as 
normal  daily  preventative  maintenance  scheduling,  about  10  of  the  20  APCs  are 
available  on  any  given  day. 


ON-BOARD  MICROPROCESSOR 

The  microprocessor,  or  portable  data  unit  (PDU),  is  a  Motorola  6800.  Located  on 
the  partition  above  and  behind  the  driver's  seat,  the  PDU  is  attached  via  a 
cable  to  a  power  supply  which  is  located  on  the  floor  behind  the  driver's  seat. 

The  PDU  contains  an  odometer,  a  clock,  and  logic  algorithms  to  interpret 
counting  sensor  and  signpost  signals.  A  time  stamp  occurs  whenever  the  bus 
passes  a  signpost  and  every  255  seconds.  There  are  no  records  indicating  that  a 
bus  has  left  a  signpost  field.  Due  to  the  lack  of  this  function,  Metro  has 
saturated  its  routes  with  signposts  in  order  to  define  location  as  precisely  as 
possible. 

The  PDU  provides  data  collection,  validation,  error  detection  and  error 
correction.  Data  records  include:  passenger  ons  and  offs,  radio  signpost 
identification,  route  location,  coach  door  activities  (wheelchair  lift 
activity,  front  and  rear  door  open,  door  close),  time  sequence,  and  accumulated 
odometer  counts. 


LOCATION  REFERENCING  METHOD 

Metro  uses  35  portable  signposts  made  by  Gould  (now  AVM)  in  Texas.  The  signposts 
are  moved  from  one  utility  pole  to  another  by  simply  climbing  a  ladder,  removing 
the  unit  and  banding  it  to  another  utility  pole.  The  signpost  codes  in  the  units 
must  be  adjusted  to  represent  the  appropriate  locations.  These  tasks  each 
require  about  5  minutes  to  complete. 

The  signposts  are  positioned  at  the  end  points  of  all  runs  and  at  beginning  and 
end  points  for  some  routes.    Additional  signposts  are  placed  on  routes  for  which 
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route  segment-level  data  are  desired.  In  this  way,  data  are  collected  for  the 
entire  route  structure. 

The  signposts  use  radio  signal  triangulation  to  transmit  a  coded  signal  with  a 
field  of  approximately  300  feet  to  the  receivers  atop  the  bus.  The  signposts 
transmit  a  signal  with  very  low  frequency  with  the  advantages  that  power  demands 
are  low  and  no  FCC  license  is  required. 

Although  Metro  is  satisfied  with  the  equipment,  a  different  type  of  maintenance 
procedure  is  desired.  At  present,  when  a  signpost  needs  servicing,  the 
installed  unit  is  removed  and  one  of  the  backups  is  put  in  its  place.  The  down 
unit  is  then  shipped  to  AVM  for  repairs.  Metro  would  prefer  that  AVM  send  the 
diagrams  and  instructional  repair  manual  to  allow  for  in-house  maintenance. 

With  the  present  hardware,  only  the  signpost  entry  record  is  written;  and  there 
Is  no  record  to  indicate  when  the  bus  left  the  field.  No  other  signpost  reading 
registers  until  the  bus  enters  another  field.  The  odometer  sensors  augment  the 
signpost  information  to  reference  location.  For  present  purposes,  this  method 
is  deemed  satisfactory,  but  Metro  believes  that  the  newer  technique  of  recording 
signpost  field  entry  and  exit  points  and  interpolating  between  the  two  points 
during  data  processing  (see  Seattle  METRO)  is  probably  a  more  precise  method. 

The  signpost  receivers,  manufactured  by  Dorne  and  Margolin  in  Bohemia,  New  York, 
are  about  one  inch  thick  and  two  feet  long.  They  are  encased  in  fiberglass  and 
positioned  horizontally  atop  the  bus.  The  original  units  were  of  faulty  design 
and  allowed  water  infiltration.  All  of  the  original  receivers  were  replaced  and 
Metro  has  had  no  problems  with  the  replacements. 


DATA  STORAGE 

The  PDU  contains  a  Datell  cassette  recorder  for  data  storage.  With  this  system, 
cassette  tapes  could  store  a  month's  worth  of  data,  but  Metro  retrieves  the  data 
more  often  to  avoid  delaying  identification  of  equipment  problems.  Currently, 
the  tapes  are  retrieved  every  two  weeks. 

There  have  been  maintenance  problems  with  the  storage  device.  A  local 
electronics  firm  worked  on  the  units  and  some  wrong  connections  were  made. 
Also,  the  devices  have  a  short  life-span  and  after  3  years,  some  of  the  units  are 
breaking  down. 


DATA  TRANSFER 

Data  transfer  is  performed  by  dispatchers  as  part  of  their  regularly  scheduled 
duties.  Once  every  two  weeks,  a  dispatcher  picks  up  an  i nti al i zati on  device  and 
blank  tapes  at  the  office  and  takes  these  to  the  APC  buses.  The  data  is  first 
initialized  by  plugging  the  device  into  the  PDU  and  punching  a  few  numbers  on 
the  device.  This  attaches  an  updated  time  stamp  to  the  data.  The  dispatcher 
then  removes  the  initialized  tape  and  replaces  it  with  another  prelabeled  tape. 
The  date,  bus  number  and  PDU  ID#  are  written  on  the  label.  The  process  takes 
about  3  minutes  per  bus. 

Metro  is  not  satisfied  with  manual  transfer  of  the  data  and  would  prefer 
automatic  transfer.  The  property  plans  to  phase  out  the  initialization  process 
and  would  like  to  convert  to  some  form  of  automatic  transfer  in  the  future. 
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STATIONARY  CPU  AND  SOFTWARE 


Metro's  APC  data  is  currently  processed  on  UTA's  PRIME  computer.  The  tapes  are 
sent  directly  to  UTA  via  Greyhound  and  the  final  reports  are  returned  within  one 
week.  This  "turn-around  time"  was  specified  by  Metro  in  its  RFP. 

As  noted  earlier,  Metro  plans  to  purchase  an  IBM  PC  AT  which  will  allow  the 
property  to  process  the  data  in-house  as  soon  as  the  software  is  modified  to 
function  on  the  IBM. 


REPORTS 

Aside  from  the  tapes,  Metro  supplies  UTA  with  the  following  information  in  order 
to  produce  reports: 

(1)  a  listing  of  daily  vehicle  assignments;  and 

(2)  a  checklist,  completed  when  the  data  is  retrieved,  indicating  any  problems 
with  the  data  or  equipment. 

Metro  was  originally  supplied  with  monthly  ridership,  route  analysis  and 
schedule  adherence  reports,  but,  because  this  amounted  to  more  data  than  current 
staff  could  handle,  quarterly  reports  were  requested  for  route  analysis  and 
schedule  adherence.  Ridership  is  still  reported  on  a  monthly  basis.  This 
approach  is  much  more  satisfactory.  Mr.  Schomisch  commented  that  UTA's  software 
is  excellent  and  produces  very  sophisticated  graphics  with  color  available  on 
request. 

The  reports  are  disaggregated  to  the  system,  route,  and  route  segment  level. 
Stop  level  data  are  available  but  this  level  of  detail  is  neither  necessary  or 
desired  at  Metro. 


APC  IMPACTS  ON  CURRENT  OPERATIONS 

Prior  to  implementing  APCs,  Metro  used  hand  counters  with  driver  input;  APCs  are 
now  used  exclusively. 

Hardware  maintenance  poses  problems  at  Metro.  Mr.  Richard  has,  on  occasion, 
worked  on  the  hardware  himself.  He  advised  that  the  project  requires  a 
considerable  amount  of  time  and  commitment;  and  that  one  person  should  be 
responsible  at  least  half  time  for  overseeing  the  APC  equipment.  He  believes 
that  many  of  the  hardware  problems  could  be  avoided  with  adequate  preventative 
maintenance. 

APCs  do  not  interfer  with  operations  since  the  APC  buses  are  simply  rotated 
throughout  the  system  all  year  long.  This  process  provides  a  33%  sample  which 
amounted  to  too  much  data  generation.  As  a  result,  Metro  reduced  the  number  of 
APC  coaches  to  15  which  was  still  considered  excessive.  Metro  contends  that  10 
APC  buses  would  be  sufficient  based  on  its  data  needs  and  the  size  of  the 
property. 
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METRO  ASSESSMENT  AND  SUGGESTIONS: 


Metro  would  not  change  its  counting  sensors  or  signposts.  As  discussed  earlier, 
the  method  of  data  storage  and  transfer  could  be  improved.  Otherwise,  Metro  is 
satisfied  with  its  present  system. 

When  asked  what  they  would  do  differently  if  they  were  to  purchase  APCs  today, 
those  interviewed  cited  the  following  precautionary  measures: 

(1)  Planning,  Operations,  and  Maintenance  need  to  work  closely  together  in 
coordination  of  the  project. 

(2)  Drivers   should  be   made   fully  aware   of   the  APCs   and   should   not  feel 
threatened  by  them  in  any  way. 

(3)  A  property  should  begin  by  using  a  prototype  on  one  or  two  routes  before 
implementing  a  full-scale  project. 

(4)  A  trained  maintenance  person  should  be  retained  on  staff  at  least  1/2  time 
to  monitor  and  service  the  APC  hardware. 

(5)  The  property  should  specify  report  formatting  to  suit  the  precise  needs  of 
the  users  of  the  data.    These  data  needs  vary  from  property  to  property. 


APC  ACQUISITION  AND  FUNDING  SOURCE 

Kalamazoo  used  an  RFP  process  to  purchase  the  hardware  and  for  software  support 
and  report  generation.  The  project  was  100%  funded  by  the  state  of  Michigan 
through  a  Public  Transit  Demonstration  Project. 


COSTS  OF  THE  APC  SYSTEM 


CAPITAL  COSTS 


Counting  Sensors: 
Mi  croprocessor : 
Transfer  Device: 
Si  gnposts : 

Installation  (bus  and  post): 

Signpost  Receiver: 

Software  Development: 

Two  year  demonstration  Project: 


$  667  per  bus 
$  2890  per  bus 

$  2000  per  initialization  unit 

$   300  per  unit 

$  2490 

unknown 

see  below 

$29680  for  maintenance,  spare  parts, 
assi  stance 

$17460     for    data     processing,  report 

production 

$  8150  for  training 
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OPERATING  COSTS 


*Urban  Transportation  Associates:         $  2700  per  month 
Maintenance:  .5  PTE  (recommended) 


*Costs  for  UTA:  to  process  data;  modify  hardware  and  provide  some  hardware 
maintenance;  to  modify  programs  for  IBM  compatibility;  and  to  produce  reports. 
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3.4   London  Transit  Commission 

Interview  With  Gordon  Arblaster,  General  Manager,  and  Darcy  Clark,  Director  of 
Planning  and  Marketing,  London  Transit  Commission,  London,  Ontario 


In  1981,  representatives  of  London  Mat  Industries  approached  London  Transit  with 
an  offer  to  install  counting  algorithms  in  one  of  their  "treadle  step"  equipped 
buses  as  part  of  a  free  six  month  demonstration.  Forty  of  London  Transit's  160 
buses  are  equipped  with  automatic  door  opening  devices  called  "treadle  steps" 
which  are  activated  when  someone  steps  on  the  bottom  step.  As  a  safety  measure, 
the  bus  must  be  at  a  complete  stop  and  the  driver  must  release  a  switch  at  the 
front  of  the  bus  in  order  for  the  device  to  work.  Treadle  steps  at  rear  doors  are 
optional  equipment  on  General  Motors  buses.  Front  door  treadles  must  be 
retrofit.  London  Mat  Industries  manufactures  these  devices. 

Following  the  demonstration  period,  London  Transit  purchased  additional  mats 
and  installed  these  on  18  buses.  From  the  initial  test  installation  to  the 
present  time,  London  Transit's  APC  system  has  consisted  solely  of  treadle  mats 
and  digital  display  panels  on  the  dashboards.  No  computers,  signposts,  or  other 
data  input  or  storage  devices  have  ever  been  used  at  London  Transit.  When  a 
survey  is  conducted  on  specific  routes,  the  driver  manually  records  counts  from 
the  display  onto  data  sheets.  This  process  requires  manual  manipulation  and 
analysis  of  the  data. 

London  Transit's  approach  to  automated  data  collection  is  an  incremental  one. 
The  property  plans  to  try  out  system  components  "piece-by-piece"  and  to  slowly 
integrate  the  system  into  transit  operations  and  planning.  For  example,  ride 
checks  are  still  performed  and  bus  drivers  continue  to  play  a  role  in  data 
collection . 

In  terms  of  project  implementation,  there  is  some  problem  with  coordination  of 
the  APC  project.  It  was  advised  that  a  property  encourage  a  high  level  of 
cooperation  between  planning  and  operations  regarding  the  APCs.  In  addition, 
efforts  should  be  made  to  allay  the  fears  of  drivers  that  their  jobs  are  not 
threatened  by  this  new  technology. 

During  the  past  two  years,  the  use  of  ride  checks  has  increased  from  their  use 
during  the  previous  two  years.  This  increase  is  due  primarily  to  the  rapidly 
declining  accuracy  level  of  the  APCs.  Initially,  the  property  sought  a  90% 
confidence  level  with  plus  or  minus  10%  tolerance.  APC  accuracy  was,  in  some 
instances,  98%  during  the  first  two  years.  London  Transit  estimates  that  over 
the  past  two  years,  the  APCs  have  deteriorated  to  about  20%  accuracy.  Harsh 
weather  conditions  over  the  past  two  winters  are  cited  as  the  cause  of  the 
problem  with  the  mats.  Evidently,  the  electronic  components  in  the  mats  are 
adversely  effected  by  the  calcium  and  salt  products  used  to  treat  the  snow,  ice 
and  slush.  Also,  melting  snow  infiltrates  the  mats  and  creates  bad  counts. 
London  Mat  Industries,  located  near  London  Transit,  is  working  on  the  mats  free 
of  charge  in  an  attempt  to  improve  their  design  and  marketability.  Also,  London 
Transit  has  installed  heaters  in  the  stairwells  of  6  of  the  APC  buses  in  an 
attempt  to  lessen  the  impact  of  the  melted  snow  and  ice  on  the  mats. 

A  second,  but  less  consequential,  source  of  error  is  overcounting  at  high  use 
stops.  Although  a  large  number  of  patrons  boarding  and  alighting  at  one  stop 
affects  the  accuracy  of  the  counts,  London  Transit  does  not  believe  this  error 
is  sufficiently  large  to  impact  decisions  that  are  based  on  the  APC  data. 
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Sizing  the  mats  to  fit  different  types  of  buses  is  another  problem  encountered 
at  London  Transit.  London  Transit  intends  to  purchase  only  buses  with  a  treadle 
rear  door  in  the  future  in  order  to  allow  for  expansion  of  APC  use.  At  present, 
the  property  is  waiting  for  London  Mat  to  perfect  the  design  of  the  mats  so  that 
they  function  in  the  harsh  climate.  Once  the  technology  has  improved,  London 
Transit  expects  to  expand  its  use  of  APCs.  A  critical  first  step  in  that  process 
is  for  the  property  to  identify  what  it  expects  from  an  automated  data 
collection  system  and  to  decide  what  resources  it  is  willing  and  able  to  commit 
to  the  project. 

London  Transit  will  continue  to  work  with  London  Mat  since  this  is  a  local 
company  and  very  accessible  for  on-going  maintenance  of  the  counters.  The  mats 
were  initially  purchased  from  London  Mat  for  this  reason  as  well  as  because  of 
the  very  low  price.  The  complete  cost  including  installation,  wiring,  and 
digital  display  was  $400  per  bus. 

London  Transit  is  75%  funded  by  farebox  revenues.  In  1984,  there  were  85  trips 
per  capita  and  20  million  total  passengers.  The  APC  project  was  75%  funded  by 
the  province  of  Ontario  and  25%  by  London  Transit. 
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3.5  Transit  Windsor 


Interview  with  David  Bjorkman,  Transportation  Scheduler,  Transit  Windsor, 
Ontario,  Canada 


Transit  Windsor's  APC  experience  began  in  1981  when  General  Motors  Corporation 
moved  an  APC  system  from  Cincinnati,  Ohio,  to  Windsor.  The  Cincinnati  APC 
project,  begun  at  Queen  City  Metro  in  1977,  was  an  experimental  program 
sponsored  by  General  Motors.  The  original  project  began  at  Queen  City  Metro  in 
Cincinnati  in  1977.  Subsequent  to  moving  the  APC  project  to  Windsor,  General 
Motors  decided  to  discontinue  its  APC  operations.  At  that  time,  the  APC  system 
was  fully  installed  at  Transit  Windsor. 

The  Queen  City  APC  application  was  referred  to  as  a  "TIS"  (Transit  Information 
System)  and  was  used  for  both  real-time  monitoring  and  off-line  report 
generation.  At  Transit  Windsor,  data  transfer  is  performed  in  real-time  (buses 
are  polled  every  30  seconds  via  the  radio  and  the  stationary  computer),  but  the 
Windsor  system  is  used  strictly  for  off-line  report  generation. 

APCs  are  installed  on  27  buses,  one  on  an  Orion  and  26  on  GM  coaches.  One  full- 
time  employee  manages  the  APC  project.  The  information  is  used  to:  create, 
evaluate,  and  adjust  schedules  and  run  times;  plan  and  justify  route  changes; 
and  monitor  driver  performance.  Uses  of  the  data  are  limited  by  a  lack  of 
software  rather  than  hardware  capability. 

Transit  Windsor  is  satisfied  that  its  APC  system  functions  according  to  original 
specifications.  The  property  would  definitely  repeat  its  APC  experience,  taking 
advantage  of  technological  innovations  occuring  in  the  past  several  years  and 
making  changes  based  on  insights  gained  from  the  present  system.  Although  APCs 
have  not  been  cost-effective  for  the  property  in  the  past  due  to  limitations 
imposed  on  the  system  by  resource  constraints,  the  system  operator  believes  that 
a  fully  operational  up-to-date  APC  system  would  be  very  cost-effective. 


EVALUATION  OF  TRANSIT  WINDSOR'S  APC  SYSTEM 


COUNTING  SENSORS 

Transit  Windsor  uses  PRODATA  dual  beam  infrared  sensors  to  count  passengers 
boarding  and  alighting  the  bus.  The  lightheads  require  very  minimal  maintenance, 
but  they  must  be  kept  free  of  dust.  Transit  Windsor  has  had  to  replace  about  two 
lightheads  per  year.  The  sensors  will  signal  a  count  only  when  the  object 
interrupting  the  infrared  stream  is  greater  than  five  inches  wide.  In  this  way, 
swinging  arms  and  handbags  are  less  likely  to  be  counted  as  passengers. 

Although  some  APC  error  is  believed  to  be  introduced  at  high  use  stops,  the 
impacts  of  these  errors  on  the  summary  data  are  considered  inconsequential  due 
to  the  fact  that  data  are  disaggregated  to  the  route  segment  rather  than  the 
stop  level.  At  the  route  segment  level,  errors  are  generalized  and  are  thus  less 
signi  f icant. 
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ON-BOARD  MICROPROCESSOR 


The  microprocessing  unit  Is  a  Motorola  6800  model.  Transit  Windsor  is  very 
pleased  with  the  accuracy  of  the  counts  accumulated  in  the  microprocessor.  When 
compared  with  manual  counts,  the  ARC  data  are  98-99%  accurate. 

The  microprocessor  flags  the  data  to  indicate  when  counts  were  taken  with  the 
bus  doors  closed.  These  flags  are  later  identified  during  data  validation 
procedures.  About  20%  of  the  ARC  sampled  trips  must  be  discarded  due  to  bad  or 
inconsistent  data.  The  system  operator  manually  deletes  trips  with  bad  data. 
Data  validation  comprises  a  major  portion  of  the  system  operator's 
responsibility.  With  conscientious  data  validation  efforts,  a  high  level  of 
accuracy  is  achieved. 

The  microprocessing  unit  processes:  counts  from  the  infrared  beams,  odometer 
readings  transmitted  through  special  wiring  linked  to  the  bus  transmission,  and 
location  reference  communicated  from  an  LSU  or  logic  support  unit.  The  LSU  is  a 
separate  piece  of  hardware  made  by  Motorola  containing  a  location  board  which 
renders  signpost  information  and  bus  ID#  to  the  stationary  computer.  The 
location  board  contains  a  solid  state  short-term  memory.  The  microprocessor  and 
the  LSU  are  very  reliable  and  require  minimal  maintenance. 


LOCATION  REFERENCING  METHOD 

Windsor  Transit  uses  a  total  of  43  signposts,  made  by  Motorola,  to  reference 
location  of  passenger  activity.  Forty-one  of  these  are  fixed  (permanent)  and 
two  are  portable  signposts.  The  portable  are  battery  powered  and  the  batteries 
have  a  very  short  life.  These  are  used  in  special  studies  only.  The  fixed 
signposts  are  A.C.  powered. 

Both  types  are  broad  signposts  transmitting  coded  radio  signals  periodically 
received  by  buses.  The  frequency  is  high  and  a  license  was  required  for  their 
use.  One  of  the  major  problems  identified  with  the  signposts  has  been  that  the 
radius  of  the  signpost  signal  is  too  wide.  In  some  cases,  the  signal  is  picked 
up  by  buses  as  far  as  1500  feet  away.  As  a  consequence,  location  reference  is 
sometimes  vague  and  it  is  difficult  to  determine  from  the  signpost  code  where 
the  buses  are  located.  To  remedy  this  problem,  the  property  has  prepared  an  RFP 
to  solicit  a  firm  to  solve  the  location  problem  either  through  hardware  or 
software  modifications. 

Another  signpost-related  problem  is  the  infiltration  of  moisture  through  the 
enclosure  and  the  antennae  (located  inside  the  enclosure  of  the  signpost 
transmitter). 


DATA  STORAGE 

Since  data  are  transferred  to  the  stationary  computer  every  thirty  seconds,  the 
short-term  solid  state  memory  in  the  LSU  is  sufficient  to  store  the  data  on- 
board the  bus. 
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DATA  TRANSFER 


Transit  Windsor  uses  radio  data  transfer  via  a  special  radio  channel.  An 
interactive  program  in  the  stationary  computer  polls  the  APC  buses  every  30 
seconds.  Beginning  with  bus  #1,  all  data  accumulated  within  the  last  30  seconds 
are  transferred  from  the  bus  to  magnetic  tape  in  the  stationary  computer.  This 
process  occurs  for  22  consecutive  hours  each  weekday.  On  weekends,  data  are 
transfered  on  demand  only. 

Although  the  property  is  satisfied  with  this  method  in  general,  several  problems 
have  been  experienced  with  it.  For  example,  the  voice  function  of  the  radio 
takes  priority  over  data  acquisition,  particularly  during  peak  service  times. 
This  is  especially  consequential  since  peak  service  data  provides  essential 
information  for  planning  and  scheduling. 

A  second  problem  with  the  data  transfer  process  was  caused  by  excessive  draining 
of  the  battery  on  weekends  by  the  data  retrieval  process.  On  Monday  mornings, 
bus  batteries  were  sometimes  found  to  be  too  weak  to  run  at  full  capacity.  To 
solve  this  problem,  a  new  schedule  for  data  retrieval  was  devised  which  excludes 
weekend  polling  except  upon  special  request. 


STATIONARY  CPU  AND  SOFTWARE 

The  computer  used  to  process  the  APC  data  is  a  MODCOMP  II  minicomputer.  This  is 
a  dedicated  unit  purchased  with  the  APC  system  from  General  Motors.  The  unit  is 
compatible  with  hard  disk  and  magnetic  tape.  Data  are  automatically  transferred 
from  the  buses  onto  the  magnetic  tape.  The  system  operator  later  transfers  the 
data  onto  disk.  One  of  the  problems  with  this  computer  is  that  it  has  only  2.5 
megabytes  of  storage  capacity.  Once  this  limit  is  reached,  new  data  are  written 
over  old  data.  As  a  result,  data  cannot  be  retained  on  disk  for  future  analysis 
and  ad  hoc  reporting.  The  data  are  stored  on  the  magnetic  tapes  for  1.5  years, 
but  transfer  to  the  disk  is  necessary  before  data  can  be  manipulated.  This 
process  requires  considerable  human  effort. 

General  Motors  developed  the  APC  software.  Since  no  programmer  documentation 
was  supplied,  the  APC  programs  cannot  be  updated  or  changed.  Several  programs 
must  be  run  to  take  the  raw  APC  data  through  all  the  stages  necessary  to  produce 
reports.  It  takes  a  total  of  about  eight  hours  to  produce  a  report  from  raw  APC 
data  on  one  ten  day  sample.  The  functions  performed  by  the  software  include: 
validating  expected  behavior  on  each  instrumented  vehicle;  appending  route 
numbers  to  the  data;  and  appending  vehicle  assignment  information  to  the  data. 
From  magnetic  tape,  a  diagnostic  report  is  accessed  which  displays  passenger 
counts  referenced  by  signpost  codes.  Schedule  files  must  be  updated  manually 
five  times  per  year  during  the  five  sign-up  periods;  these  updates  are  processed 
with  the  APC  data. 
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REPORTS 


Transit  Windsor's  ARC  system  produces  the  following  reports: 

(1)  Passenger  Loading  Profiles:    average  passenger  loads;  maximum  passenger 
loads;  and  number  of  standees. 

(2)  Time  Performance:    running  times;  percent  on  time  (early/late);  average 
speed  between  route  segments;  and  schedule  adherence. 

(3)  System  Performance  Indicators:    passenger/kilometers;  passengers  per  hour; 
and  boardings  per  kilometer. 

This  information  is  disaggregated  to  the  route  segment  level  only.  Data  are 
distributed  for  the  following  time  periods:  totals  for  weekday,  Saturday  and 
Sunday;  and  time  periods  (a.m.,  p.m.,  mid,  eve).  Reports  are  presented  in 
tabular  format  on-demand. 


ARC  IMPACTS  ON  CURRENT  OPERATIONS 

Acceptance  of  APCs  came  slowly  at  this  property  so  that  manual  data  collection 
methods  continue  to  be  used  in  conjunction  with  the  ARC  system.  As  APCs  receive 
increasing  support  by  the  Transportation  Department  at  Transit  Windsor, 
limitation  of  manual  methods  is  anticipated.  These  manual  methods  consist  of 
driver  counts  and  surveys  conducted  by  students. 

Manual  data  collection  is  used  to  augment  and  validate  ARC  data.  All  routes  are 
sampled  by  APCs  in  a  rotating  fashion  within  a  three  month  period.  The  process 
is  then  repeated.  Periodically,  this  schedule  is  interrupted  and  APCs  are  used 
to  collect  data  on  routes  which  are  the  subject  of  particular  interest  or 
controversy.  The  ARC  data  are  compared  to  data  from  driver  counts  and 
established  statistics  produced  by  the  Finance  Department. 

For  operations,  APCs  were  initially  perceived  as  a  threat  to  drivers  that  their 
performance  was  being  monitored.  The  system  operator  allayed  these  fears  by 
emphasizing  the  positive  benefits  of  APCs  for  operations  and  downplaying  the 
monitoring  capability  of  the  system.  For  example,  the  two-way  voice  radio, 
purchased  with  the  ARC  system,  was  cited  as  a  benefit  to  drivers  by  opening 
lines  of  communication  between  the  buses  on  the  street  and  the  central  office. 

A  second  issue  with  operations  pertained  to  the  assignment  of  ARC  buses.  Non- 
ARC  servicing  problems  took  priority  over  servicing  of  ARC  buses.  The  low 
priority  of  APCs  relative  to  other  operational  considerations  became  evident. 
Again,  the  benefits  of  the  ARC  system  were  emphasized.  For  example,  attention 
was  drawn  to  the  fact  the  the  two-way  radio  facilitates  on-the-road  servicing  of 
disabled  vehicles. 

Finally,  both  operations  and  maintenance  were  affected  by  the  bus  battery  drain 
caused  by  weekend  polling  of  buses  by  the  stationary  computer  to  retrieve  ARC 
data.  To  remedy  the  problem,  a  new  schedule  for  data  retrieval  was  devised 
which  excludes  weekend  polling  unless  absolutely  required. 
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TRANSIT  WINDSOR  ASSESSMENT  AND  SUGGESTIONS 


The  conflicts  arising  over  APCs  at  this  property  have  subsided  through 
cooperative  efforts  between  the  APC  system  operator  and  the  various  departments. 
Also,  increased  confidence  in  the  APC  data  facilitated  cooperation  between  the 
APC  system  operator  and  the  planners.  It  should  be  noted  that  many  of  the 
problems  experienced  by  this  property  could  have  been  minimized  if  those 
involved  were  better  informed  from  the  outset.  Lack  of  access  to  information  on 
potential  impacts  can  be  attributed  to  the  fact  that  APCs  were  a  very  new 
concept  at  the  time  this  property  adopted  the  technology. 

Future  plans  for  APCs  at  Transit  Windsor  include: 

(1)  increasing  the  disk  capacity  of  the  minicomputer.  If  the  memory  space 
capacity  of  the  existing  unit  cannot  be  sufficiently  enhanced,  the  property 
may  consider  purchasing  a  new  computer  for  use  with  APCs. 

(2)  obtaining  programmer  documentation  for  the  existing  software  so  that  it  can 
be  updated.    An  RFP  is  now  being  developed  for  this  purpose. 

(3)  remedying  the  problem  with  the  signpost  field  (see  Location  Referencing). 
Hardware  and  software  solutions  are  being  sought  through  an  RFP  process. 


APC  ACQUISITION  AND  FUNDING  SOURCE 

The  APC  project  was  funded  75%  by  the  Ministry  of  Transportation  and 
Communication  of  the  Province  of  Ontario  and  25%  by  Transit  Windsor. 


COSTS  OF  THE  APC  SYSTEM 

A  breakdown  of  system  costs  was  not  avialable.  Total  cost  for  the  system  was 
approximately  $680,000  in  1980. 
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3.6  Calgary  Transit 

Interview  with  Abe  Anwar,  Scheduler,  and  Kieth  West,  Transportation  Planner, 
Calgary  Transit,  Alberta 


Calgary  Transit  began  an  investigation  of  APCs  in  1980.  From  1980  to  1981,  a 
market  search  was  conducted  to  identify  and  evaluate  ARC  systems  available  in 
North  America  and  Europe.  During  this  time,  an  RFP  was  developed  to  select  a 
system  for  a  demonstration  project. 

The  demonstration  project,  conducted  by  Group  Five  Consultants,  commenced  in 
April,  1982.  The  project  was  designed  to  obtain  operating  experience  with  the 
system  by  fully-equipping  five  buses  and  testing  them  for  six  months.  After  one 
six  month  extension,  the  demonstration  was  completed  in  May,  1983.  Currently, 
Calgary  Transit's  ARC  system  consists  of  the  five  original  ARC  buses.  An 
evaluation  of  the  ARC  system  conducted  by  the  City  of  Calgary  found  the  ARCs 
acceptable  for  accuracy  (less  than  10%  error  ons/offs),  but  found  reliability  of 
the  equipment  unacceptable,  requiring  further  testing.  The  property  is 
conducting  a  market  research  study  to  obtain  updated  information  on 
technological  options  available.  Current  plans  are  to  expand  the  present  system 
with  twenty  additional  ARC  units. 

Calagary  Transit's  ARC  system  is  report-oriented  for  use  in  planning  and 
scheduling  activities.  In  general,  the  ARC  data  are  used  to: 

*  create,  evaluate  and  adjust  schedules  and  run  times; 

*  plan  and  justify  route  changes; 

*  evaluate  marketing  strategies; 

*  estimate  expected  revenue; 

*  monitor  driver  performance; 

*  determine  the  location  of  bus  stop  facilities. 

Use  of  ARC  data  for  these  purposes  has  been  limited  by  the  small  number  of  buses 
equipped  with  ARCs.  Three  full-time  checkers  are  retained  on  staff  and  these 
are  Calagary  Transit's  primary  data  source.  These  checkers  also  perform  ARC 
data  transfer  which  takes  about  two-to-three  hours  per  day  for  one  person. 

The  property  is  very  much  in  favor  of  ARC  systems  and  would  definitely  repeat 
its  ARC  experience.  Calgary  Transit's  goal  is  to  eventually  acquire  a  systemwide 
passenger  counting  program,  possibly  capable  of  transferring  data  by  radio 
signal  to  a  central  location. 


EVALUATION  OF  CALGARY  TRANSIT'S  ARC  SYSTEM 


COUNTING  SENSORS 

Red  Rine  infrared  light  heads  are  used  to  detect  passenger  activity.  Two  pairs 
of  light  heads  were  installed  in  the  front  door  stairwell  (to  count  both  "ons" 
and  "offs")  and  one  pair  in  the  rear  door  stairwell  (to  count  "offs").  A  set  of 
light  heads  includes  one  transmitter  and  one  detector. 

The  light  heads  are  designed  to  operate  when  the  bus  doors  are  open.  When  the 
front  door  is  open,   the  light  heads  are  operating;  when  the  front  door  is 
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closed,  the  data  are  not  transmitted  to  the  data  collection  unit  (DCU), 
containing  the  microprocessor.  The  rear  door  lightheads  become  operational  when 
the  rear  door  switch  is  operated.  In  this  way,  passengers  standing  in 
stairwells  on  overcrowded  buses  are  not  counted  as  boardings  or  alightings. 

The  initial  design  of  the  front  doors  was  to  connect  the  lightheads  to  a  micro- 
switch  which  operated  the  front  stairwell  dome  light  which  supposedly  became 
operational  when  the  front  doors  were  open.  After  it  was  discovered  that  the 
dome  light  comes  on  only  if  the  bus  headlights  are  operating,  a  modified  micro- 
switch  was  installed  at  the  front  doors. 

Conditions  which  introduce  error  into  the  data  include:  small  children  held  by 
an  adult  when  boarding  (not  counted)  and  walking  off  the  bus  (counted);  shopping 
bag  or  large  parcel  counted  as  a  passenger;  very  quick  movements;  patrons 
passing  each  other  on  the  stairwell;  swinging  arms;  and  standing  in  the 
stairwell  when  the  doors  are  open.  Of  these,  small  children  introduce  the 
largest  portion  of  the  overall  error. 

Based  on  the  evaluation  of  the  system  conducted  by  Calgary  Transit,  these  errors 
are  insufficient  to  have  a  significant  impact  on  overall  accuracy.  The  results 
of  the  test  comparing  APC  with  manual  counts  at  this  property  concluded  that  the 
hardware  achieves  an  acceptable  level  of  accuracy. 

Unit  reliability  was  not  considered  acceptable,  however,  and  considerable  down 
time  of  the  system  was  related  to  hardware  problems  such  as:  lighthead  bracket 
adjustment;  faulty  lighthead;  and  reverse  wiring.  For  this  reason,  a  second 
market  search  will  be  conducted  prior  to  purchasing  additional  hardware. 

ON-BOARD  MICROPROCESSOR 

The  Red  Pine  "data  collection  unit"  (DCU)  contains  a  Motorola  6809 
microprocessor.  The  DCU  is  mounted  to  the  modesty  panel  behind  and  above  the 
driver's  seat.  The  unit  was  positioned  to  the  far  left  edge  of  the  modesty  panel 
to  allow  access  for  maintenance.  The  DCU  is  powered  by  the  12  volt  bus  battery. 
According  to  original  design,  whenever  the  bus  was  idle  for  24  or  more  hours, 
the  unit  entered  a  low  level  state,  consuming  less  power,  and  restored  itself  to 
full  operation  when  the  bus  resumed  movement.  Restoring  the  unit  to  full 
operational  capacity  after  it  entered  the  low  level  state  was  not  consistently 
possible.  As  a  result,  the  DCU's  were  modified  to  eliminate  the  low  level  mode 
of  operation.  The  property  advises  that  the  units  be  manually  "powered  down"  if 
Inoperable  for  more  than  fourteen  days.  The  DCU  contains  spare  batteries,  but 
some  of  these  were  faulty.  As  a  result,  the  batteries  are  checked  constantly 
after  two  months  of  use. 

The  DCU  receives  signals  from  the  counting  sensors,  the  bus  odometer,  and  from 
its  own  internal  clock.  Time  is  recorded  as  relative  time  (time  since  the  DCU 
was  last  initialized)  rather  than  absolute  time  (based  on  a  24  hour  clock). 
When  the  data  are  transferred  to  diskette,  the  portable  disk  unit  (which 
contains  a  more  conventional  'clock')  appends  to  the  file  the  time  of  the 
transfer  in  days,  hours,  minutes,  and  seconds.  The  time  of  each  event  is  then 
calculated  during  data  processing  routines,  (see  Data  Transfer). 

In  addition  to  the  above  signals,  the  DCU  will  receive  signpost  codes  and  the 
software  will  process  these,  but  the  property  does  not  now  use  signposts  to 
reference  location  of  data  input. 
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LOCATION  REFERENCING  METHOD 


The  location  of  passenger  activity  is  calculated  manually  from  daily  reports 
displaying  time  and  distance  stamped  passenger  counts  at  individual  stops. 
Although  summary  statistical  reports  are  not  produced  automatically  by  the 
present  APC  system,  daily  schedule  sheets  produced  from  the  APC  data  are  used 
for  planning  and  scheduling  evaluations. 


DATA  STORAGE 

The  DCU  is  capable  of  storing  8K  bytes  of  read-write  memory.  The  following 
events  cause  a  record  to  be  written  to  memory: 

*  Passenger  activity  and  bus  leaving  the  stop 

*  Time  recorded  minimum  of  every  60  minutes  and  at  all  passenger  activity 
stops 

*  Distance  recorded  minimum  of  every  3.9  km  and  at  all  passenger  activity 
stops 

*  No  passengers  or  movement  for  one  minute 

*  Bus  leaves  inactive  stop  after  two  minutes  idle 

When  one  or  more  of  these  events  occur,  the  following  information  is  stored  in  a 
4  byte  log: 

*  Time  (in  quarter  minutes) 

*  Distance  (in  units  of  50') 

*  Cumulative  ons  and  offs 

*  Reason  for  the  log 

In  addition  to  these  records,  every  time  on-bus  data  are  transferred  to 
diskette,  they  are  preceded  by  a  header  record  which  contains:  a  4  digit  bus 
number  (entered  at  the  keyboard  at  the  time  of  transfer),  the  last  location  in 
memory  used  on  the  bus,  the  time  this  data  transfer  started,  and  the  elapsed 
time  since  the  previous  data  transfer  completed. 


DATA  TRANSFER 

Data  transfer  is  performed  manually  by  maintenance  personnel  and  checkers  using 
portable  disk  units  (PDU).  Data  are  retrieved  once  a  day.  The  maintenance 
personnel  retrieve  the  data  from  the  buses;  the  checkers  transfer  the  data  to 
the  stationary  computer. 

The  PDU  is  a  small  microprocessor-based  computer  with  a  telephone-like  12 
character  keyboard,  a  4  digit  display,  and  a  floppy  disk  drive.  It  receives  data 
from  the  buses  through  a  quick-connect  cable,  initializes  the  DCU  after  data 
have  been  transferred,  and  transmits  data  to  the  stationary  computer.  The 
microprocessor  in  this  unit  is  the  Motorola  6809,  the  same  as  in  the  DCU. 

The  PDU  draws  its  power  from  the  DCU  on  the  bus.  In  the  office,  when  data  are 
transferred  to  the  stationary  computer,  the  PDU  is  powered  by  a  separate  power 
supply  provided  as  part  of  the  system.  For  this  transmission  function,  a  key- 
driven  ASCII  terminal  is  attached  and  acts  as  the  console. 
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In  the  office,  the  PDU  incorporates  a  number  of  commands  which  allow,  for 
example,  a  directory  to  be  printed  of  the  bus  data  on  disk,  the  disk  to  be 
initialized  for  reuse,  the  raw  data  to  be  printed  directly  on  the  ASCII 
terminal,  etc.  In  the  field,  the  PDU  can  be  continually  connected  to  the  DCU  so 
that  the  contents  of  the  various  registers  in  the  DCU  can  be  displayed  at  will 
(passengers  on  and  off  by  door,  distance  travelled,  etc.)- 

Hardware  problems  with  the  PDU  include:  faulty  battery  charger  connections, 
faulty  cable  connection,  and  faulty  floppy  disk. 


STATIONARY  CPU  AND  SOFTWARE 

APC  data  are  processed  on  the  City  of  Calgary's  IBM  380  mainframe  computer.  A 
modem  is  used  to  access  the  city  computer  from  the  transit  office.  The  transfer 
of  APC  data  via  the  modem  is  a  slow  process,  sometimes  taking  an  hour  to  dump  one 
day's  data  from  five  APC  buses. 

The  software,  supplied  by  Group  Five  Consultants,  consists  of  Group  Five  SUNDAY 
catalogue  procedure  and  the  TRANSMIT  program.  The  purpose  of  the  software  is  to 
produce  a  simple  listing  of  the  data  produced  on  a  daily  basis. 

During  the  first  six  months  of  the  Demonstration  Project,  data  collection  and 
functioning  of  the  software  was  monitored  by  the  city  and  by  Group  Five 
Consulting,  which  used  a  data  route  connection  from  Ottawa.  Calgary's  Data 
Processing  Services  Department  (DPSD)  assisted  in  installing  the  software  on 
Calgary  Transit's  Spring  Gardens  Complex  computer  in  1983.  DPSD  also  assisted 
in  tailoring  the  Group  Five  software  to  Calgary's  computer  system. 

The  software  incorporates  an  algorithm  which  ensures  that  output  indicates  that 
the  bus  returns  to  the  garage  empty  and  that  at  no  time  do  more  passengers  alight 
than  were  on  the  bus  as  a  stop  was  approached. 


REPORTS 

As  stated  earlier,  no  summary  statistics  are  reported  with  the  APC  system  at 
Calgary.  A  daily  report  is  produced  which  displays  the  time,  distance 
travelled,  passenger  ons/offs,  and  cumulative  time,  distance  and  count  data. 
Passenger  load  is  also  displayed  (passenger  ons  -  passenger  offs).  The  data  are 
corrected  for  on-off  di spcrepanci es  and  other  inconsistencies.  These  corrected 
data  are  displayed  in  the  daily  reports. 
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APC  IMPACTS  ON  CURRENT  OPERATIONS 


The  phased  approach  to  APC  implementation  at  Calgary  Transit  has  helped  to 
minimize  the  initial  impacts  often  accompanying  a  transition  to  automated  data 
collection  methods.  The  project  has  been  divided  into  four  phases: 

Phase  I     -   Market  Search 
Phase  II   -   Systems  Analysis 
Phase  III  -   Demonstration  Project 
Phase  IV  -   System-wide  Implementation 

Prior  to  each  acquisition  of  APC  hardware  and  software,  the  property  conducts  a 
market  search  to  identify  system  improvements  resulting  from  technological 
advances.  By  this  means,  the  staff  is  made  aware  of  new  APC  capabilities  and 
potential  system  improvements.  Also,  the  maintenance  and  training  requirements 
associated  with  APC  use  are  identified  during  each  phase  without  incurring  the 
costs  of  a  full  system.  This  approach  is  particularly  beneficial  from  a  project 
management  perspective.  By  phasing  in  APCs,  this  new  technology  is  integrated 
slowly  throughout  the  different  divisions  allowing  time  for  adjustment. 

CALGARY  TRANSIT  ASSESSMENT  AND  SUGGESTIONS 

The  City  of  Calgary  Transportation  Department  issued  an  evaluation  report  on  its 
APC  project  in  June,  1983.  Much  of  the  information  contained  in  this  summary  is 
taken  directly  from  that  evaluation.  After  a  thorough  examination  of  the 
hardware,  software,  and  system  accuracy  and  reliability,  this  report  concluded 
that  Calgary's  APC  system  produces  an  acceptable  level  of  accuracy;  but  that  the 
reliability  of  the  hardware  was  not  acceptable.  The  recommendation  was  to 
purchase  20  additional  APC  units  following  a  market  search  to  address  the 
rel iabi 1 ity  i ssue. 

Calgary  Transit  believes  that  APCs  produce  quite  valuable  data.  They  recommend 
that  technological  improvements  be  studied  so  that  hardware  and  software 
problems  may  be  minimized  and  good  reports  can  be  produced  for  future  planning 
and  studies. 


APC  ACQUISITION  AND  FUNDING  SOURCE 

The  demonstration  project  supplier  was  selected  via  an  RFP  process.  Funding  for 
phases  I  through  III  was  shared  between  the  City  of  Calgary  and  the  Province  of 
Alberta. 
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COSTS  OF  THE  APC  SYSTEM 


Summary  of  Demonstration  Project  Expenses*  (one  year  duration) 

CAPITAL  COSTS 

Counting  Sensors: 
Microprocessor: 

Installation  (DCU  and  Sensors): 
Portable  Disk  Unit: 
Signposts: 

Installation  (bus  and  post) 
Signpost  receiver: 
Software  Development: 

OPERATING  COSTS 


Repair/Adjustment:  $  4,383 

Planning  Staff:  $13,280 

OTHER  COSTS 

Calibration:  $  1,600 

Software  Documentation:  $  3,000 

Travel  Expenses  (Consultant):  $  788 

Data  Processing  Costs:  $  3,200 

Dataroute  to  Ottawa:  $  4,628 


*Does  not  include  Phases  I,  II,  or  IV 


$  750  per  bus 
$  3,000  per  bus 
$  800  per  bus 
$  6,000  per  unit 
NOT  APPLICABLE 
NOT  APPLICABLE 
NOT  APPLICABLE 
$  3,000 
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3.7   Portland  TRIMET 


Interview  with  Doug  Allen  and  Karen  Eckert-Barcus,  Scheduling 
Technician/Analyst,  TRIMET,  Portland,  Oregon 


TRIMET  began  implementation  of  its  APC  system  in  1982  when  Red  Pine  Instruments 
equipped  40  buses  with  APCs.  TRIMET  uses  an  information  APC  system  which  is 
report-oriented  for  planning  and  scheduling.  Once  the  system  becomes  fully 
operational,  the  APC  data  will  be  used  to  create,  evaluate  and  adjust  schedules 
and  run  times;  to  plan  and  justify  route  changes;  and  to  report  on  ridership. 
Once  some  of  the  articulated  buses  are  equipped  with  APCs,  the  data  will  also  be 
used  for  Section  15  reporting. 

Due  to  the  lack  of  software  necessary  to  produce  reports,  there  is  very  limited 
use  of  boardings  and  peak  load  information.  Three  factors  have  delayed  the 
development  of  the  software  needed  to  process  the  APC  data:  (1)  design  problems 
with  the  counting  sensors;  (2)  lack  of  on-site  support  services  from  the 
supplier  to  resolve  hardware  problems;  and  (3)  limited  staffing  of  the  APC 
program. 

The  passenger  sensors,  consisting  of  infrared  multiple  beams,  were  a  new  design 
and  suffered  from  design  defects  allowing  water  damage  and  other  conditions 
which  produce  unreliable  counts.  The  responsibility  for  both  software 
development  and  hardware  maintenance  of  the  APCs  at  TRIMET  rests  almost 
completely  with  the  two  Schedule  Department  employees  interviewed.  Due  to  the 
continuous  demands  of  the  hardware,  they  spend  a  great  deal  of  their  time 
tracking  down  APC  buses  and  fixing  or  monitoring  APC  equipment  instead  of 
developing  the  software.  They  devote  almost  all  of  their  time  to  the  APC  project 
and  they  suggested  that  a  third  person  is  needed  temporarily  until  additional 
software  has  been  implemented  and  hardware  problems  are  fully  resolved.  The 
contract  with  the  supplier  includes  a  consulting  budget,  and  this  budget  is  not 
expended  when  the  manufacturer  does  not  come  on  site.  The  considerable  cost 
savings  to  TRIMET  of  maintaining  the  system  in-house  is  offset  by  the  slower 
progress  made  in  the  APC  program.  Of  the  43  buses  now  equipped  with  APCs,  36  are 
operational  at  any  given  time. 


EVALUATION  OF  TRIMET 'S  APC  SYSTEM 
COUNTING  SENSORS 

TRIMET  uses  infrared  multiple  beam  sensors  located  about  40  inches  above  the 
bottom  step  just  inside  the  front  and  rear  doors.  Proper  alignment  of  the 
lighthead  pairs  is  critical  in  order  for  the  counting  function  to  work.  TRIMET 
has  not  done  sufficient  testing  to  determine  if  the  sensors  are  in  the  most 
optimal  location. 

TRIMET  is  not  very  satisfied  with  the  sensors:  the  original  design  allowed  water 
damage;  the  beam  distribution  does  not  produce  the  most  reliable  counts;  wiring 
terminals  or  some  other  connectors  are  needed  to  ease  replacement;  and  placement 
of  the  lightheads  can  create  problems  such  as  requiring  the  removal  of 
stanchions  where  they  interfere  with  the  sensors  and  cause  poor  counts. 

Heavy  dust  accumulation  on  the  lightheads  has  interrupted  the  counts.  The 
sensors  must  be  kept  free  of  dust  and  other  obstructions  in  order  to  function. 
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TRIMET  uses  APCs  on  its  lift  equipped  buses,  but  it  does  not  monitor  lift  usage 
with  the  counters. 


ON-BOARD  MICROPROCESSOR 

The  microprocessor  on-board  the  bus  is  located  on  the  floor  behind  the  driver's 
seat.  This  unit  was  also  manufactured  by  Red  Pine  Instruments.  Counts  are 
recorded  only  when  the  bus  doors  are  open.    The  following  events  are  recorded: 

*  begin  idle  (no  bus  motion  for  more  than  1.5  minutes) 

*  end  idle 

*  time  and  distance  if  bus  goes  1.2  miles  without  stopping 

*  bus  passing  a  data  retrieval  unit 

*  time  and  distance  if  bus  sits  for  one  hour  without  moving 

*  bus  stop  with  passenger  activity 

The  following  data  are  stored  by  the  CPU: 

*  passenger  boardings  and  alightings 

*  vehicle  departure  times  from  stops 

*  time  between  stops  (relative  time  and  not  actual  time  is  stored;  the  data 
are  time  stamped  when  retrieved;  the  processing  routines  convert  the 
relative  time,  eg  -1.7  or  -3  hrs.,  into  actual  time) 

*  distance  between  stops 

For  each  event,  distance  traveled  since  the  last  event  and  the  type  of  event  are 
recorded . 

Although  there  are  high  use  stops,  distribution  of  ridership  is  does  not  appear 
to  be  the  major  factor  in  the  accuracy  of  APC  data  at  TRIMET.  According  to 
TRIMET,  APC  error  more  likely  stems  from  the  behavior  of  each  individual 
passenger  than  from  large  numbers  of  people  boarding  or  alighting  at  one  stop. 

About  20%  of  the  counts  are  lost.  The  reasons  for  data  loss  are,  in  order  of 
importance : 

1.  Vehicle  does  not  complete  its  run  as  scheduled  (does  not  meet  tolerance  for 
time  and  mi  1 eage) ; 

2.  Improper  or  unknown  assignment  imformation  (eg.  two  different  buses  both 
claim  to  be  on  the  same  run); 

3.  Counter  error; 

4.  Mileage  file  error. 

The  CPU  does  not  identify  failures  in  the  sensors.  The  software  compensates  for 
differences  of  less  than  15%  between  total  daily  boardings  and  alightings.  Data 
with  over  15%  differences  are  discarded.  Memory  space  overflow  is  handled  by 
processing  routines. 

Aside  from  occasional  vandalism,  the  only  problem  encountered  with  the 
microprocessor  has  been  the  loss  of  data  when  the  battery  is  disconnected  during 
bus  maintenance  and  repair. 

LOCATION  REFERENCING  METHOD 

At  TRIMET,  location  is  referenced  by  means  of  a  computer  generated  comparison  of 
APC  odometer  reading  with  trip  distance  files.    In  addition,  a  computer  program 
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searches  APC  records  for  bus  layover  intervals  and  compares  them  with  computer 
stored  trip  files.  This  method  seems  to  work  well  in  separating  individual 
trips.  The  software  needed  to  produce  stop  level  data  and  time  points  has  not 
been  developed;  so,  it  is  not  yet  known  whether  or  not  this  method  will  be 
successful  in  achieving  those  results. 

There  are  three  reasons  why  APC  data  will  not  match  the  schedule  data  input  by 
the  RUCUS  file: 

*  wrong  driver  input  (when  drivers  radio  in  train  #) 

*  buses  traded  during  the  day 

*  inaccurate  mileage  files 

The  advantages  of  this  method  are  that  no  signposts  or  signpost  location  files, 
and  no  software  processing  of  signpost  data  are  required.  The  disadvantages  are 
that:  distance  files  require  a  great  deal  of  manual  maintenance  to  keep  them  up 
to  date;  and  reroutes  for  construction  and  bus  trades  require  special  manual 
input  (otherwise,  the  count  data  are  rejected). 


DATA  STORAGE 

A  solid  state  memory  unit  allows  automatic  transfer  of  the  data.  This  unit  has  a 
12K  byte  capacity  (about  three  full  days  of  counts). 

DATA  TRANSFER 

TRIMET  uses  automated  retrieval  systems  at  3  garages.  As  part  of  the  normal, 
daily  routine,  whenever  an  APC  bus  returns  to  the  garage  and  stops  for  a  parking 
lane  assignment,  an  infrared  sensor/transmitter  "beams  across"  all  available 
count  data  with  no  human  involvement.  The  transfer  of  one  full  day  of  counts 
takes  two  seconds.  The  only  maintenance  of  the  retrieval  unit  is  repair  when  a 
unit  has  been  struck  by  a  bus.  Problems  with  this  method  of  data  transfer  are: 
occasional  hardware  failure  and  lack  of  access  to  the  retrieval  unit  due  to 
construction  detours,  other  vehicles,  etc. 


STATIONARY  CPU  AND  SOFTWARE 

Raw  data  are  transferred  from  the  retrieval  units  via  modems  to  a  minicomputer 
with  disk  drive.  Each  work  day,  more  or  less,  counts  are  sent  to  an  IBM 
mainframe,  with  hundreds  of  users  and  hundreds  of  terminals,  for  further 
processing.  This  hardware  was  already  available  to  TRIMET  for  other  uses  and  it 
is  not  a  dedicated  unit. 

The  software  performs  validation  checks  against  expected  behavior  on  each 
instrumented  vehicle;  appends  route  numbers  to  the  data;  and  appends  vehicle 
assignments.  Current  schedule  files  (including  mileage)  from  the  RUCUS  system 
must  be  created  and  entered  on  a  regular  basis.  However,  this  is  a  virtually 
automatic  process  (schedules  are  not  entered  separately  for  the  APC  system). 

Software  complexity  is  not  a  problem  for  users  of  the  system  who  have  computer 
skills  and  are  familiar  with  the  APC  system.  The  programs  are  written  in 
FORTRAN  and  COBOL  and  can  be  run  with  simple  instructions.  Considerable 
familiarity  with  APCs  is  necessary  for  modifying  the  programs,  however,  and 
there  is  a  trade-off  between  complexity  and  lack  of  flexibility.  Although  the 


54 


software  developed  so  far  at  TRIMET  is  not  very  complex,  it  has  limited 
capability.  For  example,  useful  reports  for  transit  functions  are  limited  to 
trip  by  trip  summaries  such  as  total  boardings  or  maximum  load.  Trip  segments  or 
individual  stops  are  not  currently  reported. 

TRIMET  is  developing  the  software  in-house.  The  analysts  view  this  as 
advantageous  since  in-house  software  development  allows  interfacing  with  the 
existing  RUCUS  system  and  the  ability  to  become  experienced  with  the  hardware  at 
the  same  time  as  the  software  is  being  developed.  1.5  person  years  have  been 
spent  on  software  development  so  far  at  TRIMET. 


REPORTS 

At  present,  TRIMET' s  APC  system  produces  one  type  of  report  which  includes  data 
on  average  boarding  rides,  average  deboardings,  and  maximum  load  on  each 
scheduled  trip.  System  total,  route  level,  and  totals  for  weekdays,  Sat.  and 
Sun.  are  also  available.  This  report  is  produced  five  times  a  year  at  the  end  of 
each  sign-up  period. 

Once  the  system  is  fully  operational,  TRIMET  planners  hope  to  have  access  to  the 
following  reports  produced  from  the  APC  data: 

*  maximum  passenger  loads 

*  route  profiles 

*  boardings  per  trip 

*  boardings  per  hour 

*  peak  load  point 

*  total  boardings  per  route  for  entire  system 

*  running  time  between  time  points 

 and  the  following  levels  of  detail: 

*  system  total 

*  route  level 

*  route  segment 

*  individual  bus  stop 

*  bus  trip 

*  sign  up 

*  totals  for  weekdays.  Sat  and  Sun 

 and  presented  in  tabular  format  periodically. 

Most  reports  are  produced  periodically  by  scheduling  staff.  Basic  data  files  are 
available  for  further  manipulation  by  users  with  computer  skills.  Only  manual 
integration  of  APC  data  with  other  information  (ie:  census  data)  is  now 
possible;  and,  at  present,  APC  data  cannot  be  accessed  for  ad  hoc  reports. 


APC  IMPACTS  ON  CURRENT  OPERATIONS 

Trips  are  uniformly  sampled  during  each  of  the  five  annual  signup  periods.  Each 
day,  a  random  sample  of  trips  is  drawn  from  a  pool  of  trips  which  have  been 
sampled  the  least  so  far,  taking  into  account  allowable  fleet  type. 
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For  the  scheduling  division,  the  main  impact  of  APCs  is  in  terms  of  extra 
personnel  to  operate  the  system.  TRIMET  estimates  the  following  costs  in  time 
to  obtain  schedule  information  once  the  software  is  in  place  and  the  system  is 
ful ly  operating: 

2  hrs/day  processing  +  1  hr/day  maintaining  data  file  +  1  hr/day  running 
programs  +  2  hours  week  preparation  for  next  week's  assignment  +  miscellaneous 
tasks  =  1  full-time  person  to  obtain  scheduling  information. 

Aside  from  scheduling,  other  divisions  affected  by  the  APC  system  are  operations 
and  maintenance.  The  APC  equipped  buses  must  travel  on  specified  routes, 
involving  operations.  Also,  the  APC  equipped  buses  get  priority  for  repair  when 
broken  down  for  non-counter  reasons,  involving  maintenance. 

To  date,  APCs  have  not  been  cost  effective  for  TRIMET,  but  the  property  has  high 
hopes  for  the  future.  Four  to  five  full-time  positions  occupied  by  traffic 
checkers  have  been  eliminated.  Thus,  there  has  been  some  cost  saving  to  date. 
However,  the  savings  from  reallocating  underutilized  service  cannot  yet  be 
attributed  to  the  counters.  Planners  and  schedule  writers  do  review  the  summary 
counts,  and  the  system  is  thus  beginning  to  be  utilized. 

TRIMET  would  do  it  again.  In  the  near  future,  they  plan:  (1)  to  switch  to  a 
better  door  sensor  design  (a  few  other  components  are  being  retrofitted  under 
warranty  to  cure  minor  design  defects);  (2)  to  equip  10  more  buses;  (3)  to 
enhance  software  to  extract  running  time  information;  and  (4)  to  refine  location 
referencing  technique  and  software  to  obtain  route  segment  data. 


APC  ACQUISITION  AND  FUNDING  SOURCE 


TRIMET  used  an  RFP  process  and  Red  Pine  was  the  only  company  to  submit  a 
proposal.  Red  Pine  supplied  the  complete  system  with  some  options  and  carried  a 
1  year  warranty  as  in  specifications.  TRIMET' s  APC  system  was  funded  by  an  UMTA 
grant. 


COSTS  OF  THE  APC  SYSTEM 


CAPITAL  COSTS 


Counting  Sensors 
Microprocessor: 
Instal lation: 
Transfer  device: 
Stationary  CPU: 


Mi  seel  1 aneous : 
Software  Development: 


$  622  per  bus 
$2158  per  bus 
$  288  per  bus 
$5000  per  unit 

$7000  for  extra  disc  drive  in 
mi  ni  computer 

$    300    per    modem    (2  extra 
purchased  for  APCs) 
$     258     per     bus  (wiring, 
brackets ,  etc . ) 

2.5  person  years  (1.5  spent 
so  far) 
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OPERATING  COSTS 

Hardware  Maintenance:  0.5  FTE 

System  operation/software  maintenance:  1.0  FTE 
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3.8  Central  Ohio  Transit  Authority  (COTA) 

Interview  with  Sue  Litzinger,  Project  Manager,  COTA,  Columbus,  Ohio 

COTA's  APC  system  was  first  implemented  in  1982  when  Urban  Transportation 
Associates  (UTA)  was  awarded  a  contract  to  conduct  a  demonstration  project. 
Under  the  original  contract,  COTA  leased  6  dual  beam  counter  units  and  8 
portable  signposts  from  UTA.  UTA  collected  data  on  all  routes  and  bus  runs  and 
provided  COTA  with  detailed  reports  for  route  planning  activities. 

During  this  demonstration  period,  signposts  were  not  used  except  to  collect 
location  data  for  special  studies.  These  experiences  proved  less  than 
successful  due  to  the  unreliability  of  the  portable  signposts.  The  most  useful 
type  of  report  provided  to  COTA  during  this  time  was  a  time  period  report.  For  a 
particular  route  or  a  particular  run,  the  data  showed  the  number  of  boardings 
for  different  time  periods.  This  report  was  produced  every  trimester  (once 
every  4  months).    Daily  totals  and  interim  reports  were  also  supplied. 

COTA  is  now  in  the  process  of  installing  a  new  system,  recently  purchased  from 
UTA.  The  system  consists  of  20  APC  buses  (one  will  be  kept  as  a  spare  and  used 
for  diagnostics)  and  50  signposts.  The  new  system  will  have  greater  capacity 
for  data  collection  and  report  generation.  In  the  past,  UTA  managed  and 
operated  the  entire  system,  ie.  data  retrieval,  data  processing,  report 
generation,  etc.  With  the  new  system,  COTA  will  be  responsible  for  everything 
except  creation  of  the  data  files.  UTA  will  continue  to  process  the  raw  APC  data 
and  produce  the  data  files  for  COTA  at  a  cost  of  $2031  per  month. 

In  the  past,  the  APC  data  were  used  to  plan  and  justify  route  changes  and  for 
UMTA  Section  15  reporting.  In  addition  to  these  functions,  the  data  will  now  be 
used  for  scheduling,  to  adjust  run  times,  to  evaluate  marketing  strategies,  and 
to  determine  fleet  needs.  The  data  will  not  be  used  to  monitor  driver 
performance;  and  there  are  no  plans  to  interface  APCs  with  the  automatic  farebox 
collection  system. 

COTA  is  enthusiastic  about  the  APC  system  as  is  evident  from  its  recent 
acquisition  of  APCs.  In  spite  of  the  on-going  costs  for  UTA  to  create  and  manage 
the  data  base,  COTA  believes  APCs  are  cost  effective.  That  is,  the  benefits 
derived  from  the  additional  information  supplied  by  the  APCs  justify  the 
expenditures.  At  present,  there  are  no  plans  to  become  fully  independent  of  UTA 
and  it  is  possible  that  UTA  will  always  process  COTA's  raw  APC  data. 


EVALUATION  OF  COTA'S  APC  SYSTEM 
COUNTING  SENSORS 

The  original  sensors  were  Prodata  dual  beam  lightheads  (I-R  beams).  The  recently 
purchased  sensors  are  Honeywell  infrared  beams.  The  sensors  are  located  at  the 
top  of  the  front  and  rear  door  stairwells.  Positioning  and  alignment  of  the 
sensors  was  not  a  problem  because  these  adjustments  had  been  made  during  the 
leasing  program. 

Fifteen  of  the  APCs  were  installed  on  the  long  (40  foot)  buses  and  five  were 
installed  on  the  short  (35  foot)  buses.  There  have  been  some  problems  getting 
the  APCs  to  function  properly  on  the  short  buses.  UTA  and  COTA's  Maintenance 
Department  have  identified  and  solved  these  problems. 
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COTA  is  very  satisfied  with  the  accuracy  and  reliability  of  the  sensors.  COTA 
is  now  in  the  process  of  testing  to  get  some  estimated  figures  on  accuracy  at  low 
and  high  use  stops.    The  results  to  date  are  very  satisfactory. 

The  only  problems  associated  with  the  I-R  beams  are  that  the  reflectors  get 
scratched  and  the  lightheads  needed  replacement  after  4  years.  Given  the  nature 
of  the  environment  in  which  they  operate  and  the  type  of  equipment,  COTA 
believes  these  conditions  are  to  be  expected,  however. 


ON-BOARD  MICROPROCESSOR 

The  microprocessor,  inside  the  PDU  or  portable  data  unit,  is  located  under  the 
driver's  seat.  This  unit  contains  an  odometer,  a  clock,  and  a  modem  which 
translates  the  signpost  signal  from  the  receiver  to  a  cassette  tape. 

Data  input  is  activated  by  door  switches  which  signal  when  doors  close.  All  data 
accumulated  from  the  last  data  input  are  written  to  record  when  the  front  or 
rear  doors  close.  It  was  recently  discovered  that  counts  accumulate  in  the  PDU 
when  the  doors  are  closed  and  the  bus  is  moving.  Thus,  if  someone  is  standing  or 
moving  in  the  stairwell  between  stops,  counting  takes  place.  The  next  time  the 
doors  close  this  activity  is  written  to  record. 

Data  is  written  to  tape  whenever  a  bus  enters  and  leaves  a  signpost  field  and 
when  256  seconds  elapse  since  the  last  record  was  written.  Each  time  a  record  is 
written  (data  input),  data  are  time  and  odometer  stamped.  The  time  stamp  is 
based  on  a  24  hour  clock.  By  this  means,  time  and  distance  between  stops  are 
calculated. 

"On-off  discrepancies"  are  common  and,  in  most  cases,  more  alightings  than 
boardings  are  recorded.  This  discrepency  is  reduced  by  lighthead  adjustment  and 
is  not  a  major  concern.  In  the  past,  COTA  has  used  only  the  "on"  counts  because 
the  data  were  used  to  determine  the  number  of  passengers  boarding  the  bus  by 
time  of  day.  Data  with  on-off  discrepancies  exceeding  10%  have  been  discarded 
during  processing  routines.  Now  that  COTA  plans  to  use  the  data  for  scheduling, 
APCs  will  be  used  to  derive  maximum  load  counts  and  some  adjustment  algorithm 
will  be  used  in  the  processing  routines  (not  the  microprocessor)  to  set  the  load 
equal  to  zero  and  compensate  for  on-off  discrepancy  at  the  end  of  every  trip. 

The  microprocessor  has  been  very  reliable.  There  have  been  some  problems  with 
the  link  between  the  microprocessor  and  the  cassette  storage  unit,  however.  UTA 
has  resolved  this  problem. 

LOCATION  REFERENCING  METHOD 

COTA  uses  50  Motorola  signposts  to  reference  location.  Forty  of  these  are 
"permanent"  and  ten  are  "portable".  The  A.C.  powered  permanent  signposts  tap 
into  the  power  source  of  the  traffic  control  boxes  (TCB).  These  devices  are 
enclosed  in  small  grey  boxes  that  blend  in  with  and  are  attached  to  the  TCB.  In 
order  to  install  these  boxes  and  to  use  the  power  supplies,  permission  was 
sought  from  the  local  jurisdictions.  COTA  had  no  problem  in  obtaining  their 
permission. 

The  portable  signpost  is  a  small  grey  box  attached  to  a  second  grey  box 
containing  the  battery.    These  devices  are  strapped  to  utility  poles  by  a  band 
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and  are  easily  transferred  from  one  pole  to  another.  The  portable  devices  are 
very  unreliable  and  require  a  great  deal  of  maintenance.  Also,  the  batteries 
have  a  very  short  life  and  need  constant  replacement.  To  resolve  these  problems, 
UTA  is  installing  solar  panels  in  the  portable  signposts.  The  permanent 
signposts  are  very  reliable  and  require  minimal  maintenance. 

Both  types  of  signpost  are  broad  signposts  transmitting  coded  radio  signals 
periodically  received  by  buses  within  a  radius  of  150  feet.  The  frequency  is 
173.4  Hz  which  is  close  to  the  frequency  of  a  local  radio  station.  There  have 
been  no  interferences  from  outside  signals.  COTAwill  receive  an  FCC  license  to 
operate  the  signposts. 

COTA  initially  experienced  some  problems  with  the  signposts  and  receivers  (also 
made  by  Motorola).  She  receivers  need  to  be  fine  tuned.  Some  of  the  receivers 
pick  up  signpost  signals  as  far  as  500  feet  away  while  others  do  not  receive  the 
signals  at  all.  Although  each  bus  is  now  consistently  receiving  signpost 
signals,  fine  tuning  is  still  needed  so  that  each  bus  will  receive  the  signal  at 
about  the  same  range.  COTA  suggests  that  200-300  feet  is  probably  the  optimal 
range,  but  the  critical  issue  is  for  there  to  be  no  variation  in  the  ranges  as 
this  affects  the  locational  accuracy  of  the  schedule  adherence  data. 

The  signposts  are  positioned  at  major  transfer  points  and  major  time  points  and 
are  spaced  an  average  of  2  to  3  miles  apart.  For  express  routes,  they  are  placed 
at  the  downtown  end  only.  COTA  has  many  interlining  routes  and  there  are  an 
average  of  4  signposts  per  route.  In  the  future,  COTA  plans  to  have  a  signpost 
at  the  end  of  major  lines. 

COTAwill  use  the  signposts  for  route  and  route  segment  level  data,  and  will  not 
reference  individual  stops. 


DATA  STORAGE 

Data  are  stored  in  a  Datell  cassette  tape  unit  in  the  PDU.  The  data  are 
retrieved  once  a  week.  Longer  storage  is  possible  but  not  desired  due  to  the 
hazards  associated  with  long  term  storage  (see  OC  TRANSPO  summary  and  others). 


DATA  TRANSFER 

Data  transfer  is  a  two  step  process.  First,  the  cassette  tapes  are  replaced  and 
the  PDU's  (portable  disk  units)  are  initialized  (see  Kalamazoo  case  study)  by  an 
automated  systems  technician,  hired  full-time  to  monitor  APCs.  The  technician 
schedules  the  buses  into  the  garage  one  day  a  week  to  retrieve  the  data  and  to 
check  on  the  hardware.  When  the  tapes  are  retrieved,  an  audit  is  performed  to 
obtain  measures  on  the  status  of  the  hardware,  ie.  the  number  of  times  the  doors 
opened,  the  number  of  boardings. 

Secondly,  the  tapes  are  sent  to  UTA  where  another  transfer  takes  place.  The 
cassettes  are  inserted  into  a  Kennedy  tape  drive  one  at  a  time.  This  machine 
transfers  the  data  onto  a  9  track  tape.  The  process  is  very  slow,  taking  20 
minutes  for  each  cassette. 

COTA  would  prefer  automatic  transfer  of  the  data,  but  this  option  was  not 
researched  or  considered  during  the  acquisition  process. 
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STATIONARY  CPU  AND  SOFTWARE 


UTA  will  continue  to  create  the  data  base  for  COTA  at  a  cost  of  about  $2000  per 
month.  Three  days  after  UTA  receives  a  tape,  it  will  send  COTA  some  preliminary 
information:  diagnostics  and  daily  totals.  Within  10  days,  UTA  will  send  all 
the  data  files  on  both  diskette  and  9  track  tape. 

The  data  processing  by  UTA  will  include  matching  route-run  assignments  and 
correlating  ARC  data  with  bus  schedule  and  scheduling  data.  In  addition  to  the 
cassettes,  COTA  will  supply  UTA  with  the  following  information  and  updates: 

*  locations  of  signposts 

*  distances  between  stops 

*  outstation  and  instation  times  (to  delete  garage  time) 

*  Rucus  trip  f i le 

*  vehicle  assignments 

In  addition,  COTA  will  append  route  and  run  numbers  to  the  data.  One 
disadvantage  of  this  arrangement  is  that  the  data  base  cannot  be  manipulated  by 
COTA  for  exceptional  analyses.  As  a  clause  in  its  contract,  UTA  will  accomodate 
new  data  base  needs  as  "special  requests"  for  a  negotiable  fee.  COTA  budgeted 
$3400  per  year  for  special  requests. 

To  generate  reports,  COTA  will  use  SPSS  PC  packaged  software  on  its  IBM  XT 
computer.  All  reports  will  be  preformatted.  COTA  will  also  have  access  to  Ohio 
State  University's  (OSU)  PRIME.  UTA  will  send  the  9  tracks  for  use  on  the  PRIME. 
OSU  has  a  color  plotter  and  a  high  speed  printer.  This  system  will  be  used  with 
the  APCs  to  produce  special  reports. 


REPORTS 

COTA  expects  the  new  software  to  provide  the  following  information: 

(1)  Passenger  loading  profiles:  average  and  maximum  passenger  loads;  load  as  a 
percent  of  seated  capacity;  time  with  standees;  standees  as  a  percent  of 
seated  capacity;  and  distance  travelled  with  standees. 

(2)  Time  performance:  running  time;  arrival  time;  departure  time;  layover 
time;  percent  on  time;  minutes  early/late;  run  time  between  time  points; 
schedule  adherence;  and  dwell  times, 

(3)  Performance  indicators:  passenger  miles;  passengers  per  hour;  boardings 
per  mile;  and  boardings  per  hour. 

Data  will  be  available  on  the  route  and  route  segment  level  and  for  vehicle 
blocks  and  bus  trips.  All  data  will  be  available  for  time  periods,  weekday  and 
weekend  totals,  monthly  totals,  and  sign-ups.  Reports  will  be  routinely 
produced  periodically  with  some  data  reported  every  two  weeks. 
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APC  IMPACTS  ON  CURRENT  OPERATIONS 


APCs'  major  impact  at  COTA  has  been  in  the  MIS  (Management  Information  Services) 
Division.  In  that  division,  a  full  time  person  was  hired  to  assign  APC  buses,  to 
monitor  APC  performance,  to  conduct  the  data  transfer,  and  to  communicate  with 
UTA  on  the  status  of  APCS.  In  addition,  a  project  manager  spends  .5  FTE 
coordinating  the  APC  program. 

Although  MIS  is  the  only  division  directly  involved  with  the  APC  project,  other 
divisions  such  as  marketing,  service  development,  and  scheduling  request 
information  on  specific  routes  and  route  segments.  These  requests  are  made  to 
the  technician  who  communicates  the  assignments  to  the  vehicle  line-up  people. 
These  people  report  back  later  in  the  day  with  an  account  of  exactly  where  the 
APC  buses  were  during  the  day.  The  technician  keys  this  information  into  a  D- 
Base  II  program  and  gives  the  diskette  to  UTA  periodically.  UTA  has  an 
assignment  algorithm  that  matches  the  date  and  bus  number  with  the  assignment 
information  on  the  diskette. 

Drivers  have  never  been  involved  in  the  data  collection  process  at  COTA,  and 
they  do  not  take  part  in  the  APC  system.  COTA  continues  to  use  manual  data 
collection  (ride  checks)  in  conjunction  with  APCs  in  recognition  of  the  most 
efficient  application  of  each  data  collection  resource. 

Planning,  Maintenance,  and  Operations  cooperate  on  the  APC  project  and  there  are 
positive  and  open  lines  of  communication  between  the  APC  technician  and  these 
departments. 


COTA  ASSESSMENT  AND  SUGGESTIONS 

Based  on  past  experience,  COTA  views  the  APC  project  as  more  cumbersome  than 
complex.  For  example,  when  a  change  is  made  to  a  route,  considerable  receding 
is  necessary.  Also,  ad  hoc  reporting  requires  a  great  deal  of  effort  on  UTA's 
part.  (UTA  has  extensively  modified  the  software  since  its  original  development 
by  General  Motors . ) 

There  have  been  problems  with  the  tapes  not  being  properly  demagnetized  and  new 
data  were  read  over  old  data.  UTA  edited  the  data  but  additional  editing  was 
done  by  COTA  on  occasion. 

COTA  offers  the  following  suggestions  for  a  property  to  follow  prior  to 
implementing  an  APC  system: 

(1)  The  property  should  identify  its  needs  and  determine  how  APCs  will  satisfy 
these  needs. 

(2)  When  writing  specifications  for  APCs,  the  property  should  present  exactly 
what  it  expects  the  vendor  to  supply. 

(3)  Logic  to  ensure  that  counting  does  not  take  place  while  the  doors  are 
closed  and  when  the  bus  is  moving  should  be  built  into  the  microprocessor 
as  a  safeguard  against  overcounting. 

(4)  The  property  must  understand  that  the  APC  software  is  as  crucial  to  the 
success  of  the  APC  system  as  the  hardware. 
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APC  ACQUISITION  AND  FUNDING  SOURCE 


COTA  used  an  RFB  (request  for  bids)  process  to  solicit  vendors  for  its  APCs. 
There  were  two  bids,  one  of  which  was  unresponsive  to  the  specifications.  The 
project  was  funded  80%  by  an  UMTA  Capital  Grant  and  20%  by  COTA. 


COSTS  OF  THE  APC  SYSTEM 


1983  14  month  demonstration; 


1984  Purchase  of  APC  System: 
CAPITAL  COSTS 
Sensor  Set: 

Portable  Data  Units: 
Signposts: 

(including  installation) 
Initial ization  Unit: 
Training  and  Material: 

Software: 


Total  Capital  Cost; 
OPERATING  COSTS* 
1983-1984: 


Aug. -Dec.  31,  1984; 


$  60,000  (Includes  cost  of:  leasing  hardware  to 
equip  6  buses;  access  to  8  signposts;  all  hardware 
maintenance,  data  processing,  data  transfer,  and 
report  generation. ) 


1985: 


$  26,300  (Includes  I-R  sets,  door  switches, 
antenna,  odometer,  installation  and  wiring  for  20 
buses) 

$102,585     (For  21  PDUs  including  installation) 

$  64,000    (For  40  A.C.  signposts) 
$  14,000  (For  10  portable  signposts) 

$   2,500    (For  one  unit) 

$  4,000  (For  manuals,  guides,  documents,  and 
trai  ni  ng) 

$  38,930  (Includes  2  copies  of  SPSS  PC;  report 
generating  command  files;  and  copies  of  Fortran 
software  used  to  create  data  base  (COTA  requested 
these  programs  in  order  to  safeguard  its 
investment)) 

$252,315     (Total  initial  cost  for  system) 


$  6,000  per  month  (paid  to  UTA  for  continued 
leasing  of  equipment  and  report  generation  between 
the  end  of  demonstration  and  the  beginning  of  new 
system. ) 

$  6,000  per  month  (to  UTA  for  data  transfer, 
maintenance,  data  processing,  and  report  generation 
on  new  system) 

$  2,031  per  month  (to  UTA  for  data  processing, 
editing,  and  creation  of  data  files  including 
transfer  to  9  track  tapes.) 
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1983-1985  Personnel:  .5  FTE   Project  Manager 

1  FTE  APC  Specialist 


*Operating  costs  also  include  data  processing  machine  time  and  human  effort. 
These  costs  are  likely  to  be  less  for  COTA  than  for  some  systems  since  the  data 
base  is  not  created  in-house  at  COTA. 
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3.9  Chicago  Transit  Authority  (CTA) 

Interview  with  Lynn  Ritter,  APC  Specialist,  CTA,  Chicago,  Illinois 

CTA  began  implementation  of  an  APC  system  in  the  summer  of  1983  with  a  five  month 
demonstration  project  integrated  by  Urban  Transportation  Associates  (UTA).  At 
the  end  of  the  demonstration,  funding  was  approved  by  the  Authority  to  lease  the 
equipment  and  continue  the  services  of  UTA.  Capital  funding  for  the  first  phase 
of  implementation  and  purchase  of  a  complete  APC  system  has  recently  been 
approved. 

During  the  demonstration  and  leasing  periods,  6  buses  were  equipped  with  APCs  at 
one  of  the  nine  CTA  garages.  Because  of  the  very  small  APC  sample  relative  to  the 
size  of  the  property,  no  adjustments  were  made  to  the  size  of  the  manual  data 
collection  force  (28  people)  because  of  the  APCs.  The  reports  produced  by  APCs 
were  designed  to  meet  the  specified  data  needs  of  the  property.  There  are  five 
sign-ups  or  "picks"  per  year  and  specific  routes  were  sampled  for  each  report 
requested  from  UTA  for  each  pick.  Generally,  sampling  would  be  concentrated  on  a 
single  route  during  a  pick  enabling  a  set  of  reports  to  be  produced  for  a  route 
analysi  s. 

UTA's  services  to  CTA  are  similar  to  UTA's  services  in  the  past  to  COTA  in 
Columbus,  Ohio  (see  COTA  Summary).  CTA  leased  the  equipment  used  during  the 
demonstration  and  will  now  purchase  the  software  and  additional  hardware  from 
UTA.  Because  the  decision  to  go  ahead  with  APC  acquisition  is  a  very  recent  one, 
the  specifications  for  the  system  have  not  yet  been  developed.  Plans  are  to 
equip  270  buses,  or  11%  of  the  total  fleet,  with  APCs  over  a  period  of  several 
years. 

CTA's  APC  system  is  report-oriented  for  planning  and  scheduling.  Approximately 
1.5  FTE  in  planning  are  spent  managing  the  APC  project.  Generally,  APC  data  are 
used  at  CTA  to: 

*  create,  evaluate  and  adjust  schedules  and  run  times 

*  plan  and  justify  route  changes 

*  section  15  reporting 

*  respond  to  non-standard  inquiries  such  as  questions 
regarding  passenger  activity  at  particular  stops. 

CTA  is  satisfied  with  the  performance  of  its  APC  system  and  would  repeat  its  APC 
experience.  The  major  problem  with  APCs  encountered  by  CTA  has  been  related  to 
unit  reliability.  Much  time  and  effort  has  been  expended  working  with  UTA  to 
resolve  some  of  the  reliability  problems.  In  addition,  the  age  (9  years)  and 
poor  health  of  the  buses  equipped  with  APC  hardware  contribute  to  the  down  time 
of  the  APC  system. 


EVALUATION  OF  CTA'S  APC  SYSTEM 
COUNTING  SENSORS 

The  hardware  was  supplied  by  UTA  and  the  make  and  manufacture  was  not  known  at 
the  time  of  the  interview.  The  sensors  are  reflective  dual  infrared  beams.  The 
reflectors  are  located  on  the  modesty  panel.  The  light  heads  are  on  the 
dashboard  at  the  front  of  the  bus  and  on  a  bracket  mounted  to  the  front  of  the 
rear  door.  Door  switches  are  also  used  to  assure  that  counting  takes  place  only 
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when  the  doors  are  open.  CTA  is  very  satisfied  with  the  reliabilty  and  accuracy 
of  the  sensors. 


ON-BOARD  MICROPROCESSOR 

The  make  of  the  microprocessor  is  a  PROLOG  6800;  but  name  of  the  manufacturer 
was  not  known.  The  following  events  cause  records  to  be  written: 

*  front  and  rear  door  opening  and  closing 

*  signpost  field  entry  and  exit 

*  time  stamp  every  256  seconds  if  no  other  event  occurs 

Most  of  the  hardware  problems  relate  to  the  power  supply  needed  by  the 
microprocessor.  The  buses  have  12  volt  electrical  systems.  The  way  the  unit  is 
currently  designed,  a  slight  deterioration  in  the  bus  battery  power  results  in 
the  loss  of  microprocessor  initialization.  When  this  occurs,  no  data  is  recorded 
until  the  microprocessor  is  manually  reinitialized. 

Failures  in  the  sensors  are  detected  via  a  portable  diagnostic  unit  which  plugs 
into  the  microprocessor  and  displays  the  front  and  rear  door  counts.  This  unit 
is  used  for  testing  of  the  equipment  as  well.  Sensor  and  microprocessor 
failures  may  also  be  detected  in  the  diagnostic  step  of  data  processing. 

Passenger  boardings  and  alightings  referenced  by  location  are  the  data  stored  by 
the  microprocessor.  In  addition,  the  driver  fills  out  a  trip  ticket  for  all 
runs  indicating  what  routes  that  bus  has  taken  that  day.  The  information  from 
these  tickets  is  later  key  punched  into  a  data  file  for  matching  with  the  APC 
data. 


LOCATION  REFERENCING  METHOD 

CTA  uses  Motorola  signposts  to  reference  location  of  data  input.  Currently  450 
signposts  are  installed  on  all  routes.  The  reason  that  CTA  has  so  many  signposts 
is  because  the  signposts  are  used  for  emergency  response  as  well  as  APCs.  In 
fact,  the  signposts  had  already  been  in  place,  some  as  early  as  1970,  before 
APCs  were  implemented  at  CTA. 

The  signposts  are  broad  signposts  transmitting  coded  radio  signals  periodically 
received  by  buses  within  range.  Most  of  the  signposts  operate  on  A.C.  power  and 
have  little  or  no  maintenance  requirements.    Maintenance  is  contracted  out. 

DATA  STORAGE 

Data  are  stored  on-board  the  bus  on  cassette  tape. 


DATA  TRANSFER 

Data  transfer  at  CTA  is  performed  by  the  vendor  at  least  once  every  two  weeks. 
Portable  units  are  used  to  initialize  the  microprocessor.  During  transfer,  the 
tapes  are  replaced,  the  unit  is  initialized,  some  diagnostics  are  done  on  the 
hardware,  and  the  sensors  are  tested.  The  entire  process  takes  about  20  minutes 
per  bus.  The  simplicity  of  the  process  is  considered  an  advantage  of  manual 
transfer.    However,  the  time  delay  between  observation  and  reporting  of  events 
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is  a  major  disadvantage.  To  overcome  this  disadvantage,  tapes  can  be  changed  on 
a  weekly  basis. 


STATIONARY  CPU  AND  SOFTWARE 

At  present,  CTA's  APC  data  are  processed  on  UTA's  PRIME  computer.  Once  CTA  is 
independent  of  UTA,  the  data  will  be  processed  on  CTA's  Sperry  UNIVAC  1100 
mainframe  computer.  CTA  will  need  to  purchase  equipment  to  translate  the  data 
from  the  cassettes  to  magnetic  tapes.  Both  data  file  creation  and  report 
generation  will  be  performed  on  the  UNIVAC.  The  software  will  be  purchased  from 
UTA  and  will  include  the  data  base  program  and  the  command  files  for  SPSSX. 

Software  costs  are  estimated  at  between  $100,000  and  $200,000.  Although  a 
breakdown  of  the  software  costs  was  not  available,  the  cost  of  the  modifications 
needed  to  convert  the  software  from  PRIME  to  UNIVAC  use  is  expected  to  be  the 
most  expensive  element  in  overall  software  costs.  The  costs  of  the  translation 
have  not  yet  been  identified  by  UTA. 

In  addition  to  the  APC  data,  the  driver  trip  ticket  data,  end  of  line  adjustment 
information  and  data  on  the  number  of  feet  between  stops  must  be  entered  for 
stop  level  data.  Finally,  an  automated  schedule  file,  developed  in-house,  is 
used  to  match  schedule  information  with  APC  data. 


UTA  currently  supplies  CTA  with  reports  produced  from  the  following  APC  data: 


These  reports  are  produced  mostly  on-demand  with  a  few  reports  produced 
routinely  for  scheduling.  The  APC  system  is  capable  of  disaggregating  these 
data  to  the  system,  route,  bus  trip,  route  segment  and  bus  stop  level. 
Potential  temporal  distribution  of  the  data  can  be  for  seasons  or  sign-ups, 
monthly,  weekday,  Saturday  and  Sunday,  time  periods  and  15  minute  periods  during 
peak  traffic  hours.  CTA  has  received  reports  at  all  of  these  levels  except 
monthly  totals  which  have  not  been  requested.  Graphics  are  seldom  requested  and 
reports  are  usually  in  tabular  format.  In  additon,  diagnostic  reports  on  the 
status  of  the  hardware  are  supplied  four  times  per  month  to  CTA. 


APC  IMPACTS  ON  CURRENT  OPERATIONS 

Because  such  a  small  portion  of  the  fleet  has  been  equipped  with  APCs  to  date  and 
because  so  much  of  the  work  is  performed  by  UTA,  the  impacts  of  APCs  have  yet  to 
be  fully  realized.  The  addition  of  1  FTE  for  APC  coordination  and  management  and 
another  .5  FTE  for  assistance  have  been  the  most  immediate  impacts  noted  so  far. 


REPORTS 


PASSENGER  LOADING  PROFILES 


TIME  PERFORMANCE 


*  average  passenger  loads 

*  maximum  passenger  loads 

*  load/capacity 

*  route  prof i les 

*  maximum  load  points  and  locations 

*  boardings  by  stop 

*  al ighti ngs  by  stop 


*  running  times 

*  signpost  field  enter  and  exit 

*  layover  time 

*  minutes  early/late 

*  average  speed  between  time 


poi  nts 

*  schedule  adherence 
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CTA  ASSESSMENT  AND  SUGGESTIONS 


Leasing  a  few  units  was  advised  for  a  beginning  APC  implementation  to  discover 
how  well  APCs  fit  into  the  operations  of  the  transit  district.  Slow,  careful, 
incremental  implementation  was  also  advised. 


APC  ACQUISITION  AND  FUNDING  SOURCE 


Funding  for  the  demonstration  project  came  from  CTA's  operating  budget.  UTA  was 
chosen  to  perform  the  demonstration  project.  They  had  provided  CTA  with  an 
unsolicited  proposal  in  1982.  The  concept  of  a  passenger  counting  system  that 
integrated  hardware  and  software  such  as  the  system  proposed  by  UTA  was  deemed  a 
project  worth  testing.  UTA  was  found  to  be  the  only  vendor  in  the  APC  industry 
offering  the  integrated  hardware/software  system. 

The  property  is  currently  funding  the  lease  program.  The  planned  acquisition  of 
the  system  will  be  funded  20%  by  local  match  and  80%  by  UMTA. 


COSTS  OF  THE  APC  SYSTEM 


Demonstration  Project; 
Leasing: 


$   40,000  for  five  months 

$  1,700  per  month  per  bus  for 
lease,  maintenance,  and  report 
generation 


Estimated  Cost  of  Purchase: 


On-Board  Equipment:  $    8,000  per  unit 

Estimated  Software:  $100,000-$200,000 
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3.10   Kitchener  Transit 


Interview  with  Vince  Mauceri ,  Senior  Transportation  Planner,  Kitchener  Transit, 
Ontario,  Canada 


Kitchener  is  now  in  the  process  of  implementing  an  APC  system.  The  expectation 
is  that  the  system  will  be  operational  by  the  end  of  June,  1985.  Twenty  buses  are 
being  equipped  with  APCs.  Of  these.  Kitchener  will  operate  up  to  17  at  any  given 
time.  The  APC  system  will  be  report  oriented  for  planning  and  scheduling.  APC 
data  will  be  used  to  create,  evaluate,  and  adjust  schedules  and  run  times;  to 
plan  and  justify  route  changes;  to  evaluate  marketing  strategies;  to  determine 
fleet  needs;  to  monitor  driver  performance;  to  determine  location  of  bus  stop 
facilities;  to  monitor  schedule  adherence;  to  determine  location  or  removal  of 
bus  shelters;  and  to  perform  cordon  counts. 

Kitchener  has  contracted  with  Systemware,  Inc.  and  Sigma  Star  Research  and 
Consulting  Corporation  to  develop  the  software  to  process  the  APC  data. 
Mississauga  Transit,  another  Ontario  property,  also  has  contracted  with  this 
company  for  software  development.  Although  both  Kitchener  and  Mississauga 
Transit  Properties  will  have  the  same  software  and  will  use  the  same  computer 
(VAX  minicomputer),  they  will  use  different  on-board  equipment.  This 
arrangement  is  part  of  an  experiment  planned  by  the  Province  of  Ontario  in  an 
attempt  to  obtain  software  which  will  have  uniform  application  to  all  properties 
in  the  province. 

Kitchener  planners  believe  the  APCs  will  be  cost  effective  by  virtue  of  their 
replacing  15-20  ride  checkers,  saving  the  property  about  $18,000  annually.  They 
contend  that  the  APC  system  should  more  than  pay  for  itself  over  a  two  year 
period.  Plans  for  the  future  include  expanding  the  APC  system  to  include  real- 
time monitoring  capability  and  acquiring  signposts  within  two  to  three  years. 


EVALUATION  OF  KITCHENER'S  APC  SYSTEM 
COUNTING  SENSORS 

Kitchener  will  use  treadle  mats  manufactured  by  London  Mat  Industries.  These 
mats  are  being  installed  on  the  two  steps  at  the  front  and  rear  stairwells. 

Kitchener  staff  will  perform  the  actual  installation  of  the  mats.  The  supplier 
will  train  the  maintenance  staff  in  the  proper  installation  and  maintenance  of 
the  equipment. 

ON-BOARD  MICROPROCESSOR 

The  microprocessors  are  manufactured  by  Pachena  Scientific  and  Industrial 
Electronics  Inc.,  British  Columbia.  They  will  be  mounted  on  the  floor  or  modesty 
panel  behind  the  driver.    The  following  events  will  be  recorded  by  the  unit; 

*  passenger  ons  and  offs 

*  front  and  rear  door  opening  and  closing 

*  time  between  stops  (24  hour  clock)  for  vehicle  arrival  times 

*  distance  between  stops  (odometer  readings  to  reference  location) 

*  memory  space  overflow 
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*  idl ing  events 

*  record  of  date  and  time  of  last  data  retrieval 

*  built-in  PCU  (Passenger  Counting  Unit)  identification  attached  to  the  bus 
number  (if  possible) 

Failures  in  the  passenger  counting  sensors  will  be  identified  through  use  of  a 
portable  testing  unit  supplied  with  the  PCU.  The  microprocessor  on-board  the  bus 
will  transmit  a  signal  to  the  portable  testing  unit  when  data  are  in  error  due  to 
hardware  failure  (see  Data  Transfer). 


LOCATION  REFERENCING  METHOD 

Kitchener  plans  to  use  a  computer  generated  comparison  of  APC  odometer  reading 
to  stop  by  stop  distance  files  to  reference  location  of  passenger  activity. 
With  this  technique,  a  computerized  schedule  file,  Bus-Sched,  is  compared  with 
the  distances  recorded  by  the  microprocessor.  Because  the  system  is  not  yet 
implemented,  no  assessment  of  the  method  at  Kitchener  is  available.  Refer  to 
TRIMET  summary  for  more  information  on  this  approach. 


DATA  STORAGE 

The  portable  data  unit  contains  a  solid  state  memory  device  which  has  a  storage 
capacity  of  up  to  128K  bytes. 


DATA  TRANSFER 

Kitchener  plans  to  use  a  cable  retrieval  system  located  inside  the  garage  in  the 
service  fueling  area.  The  device  consists  of  a  standard  cable  with  an  RS-232 
connector.  While  vehicles  are  being  serviced  late  at  night,  a  serviceman  will 
plug  the  cable  with  the  RS-232  into  the  APC  unit  located  on  the  modesty  panel 
behind  the  driver's  seat.  Once  the  data  have  been  transferred  to  the  central 
computer,  an  LCD  display  on  the  microprocessor  unit  located  on  the  bus  will 
indicate  whether  a  successful  or  unsuccessful  transmission  was  made. 


STATIONARY  CPU  AND  SOFTWARE 

Data  collected  by  the  APCs  will  be  processed  by  a  Digital  Equipment  Corporation 
(DEC)  VAX  11/750  minicomputer,  purchased  in  1984  from  Plessey  Peripheral  Systems 
Canada,  Ltd.  The  total  purchase  included  the  VAX,  two  dot  matrix  printers,  four 
terminals,  one  console  printer/terminal,  one  tape  drive,  the  VMS  operating 
system,  450  MB  disk,  and  Fortran  and  Basic  compilers. 

In  addition  to  processing  APC  data,  the  computer  will  be  used  for  several  other 
functions  such  as:  scheduling,  runcutting,  statistical  analysis,  spread  sheet 
applications,  advertising  inventory,  financial  planning,  etc. 

In  order  for  the  APC  to  produce  useful  reports,  it  is  necessary  to  extract 
"vehicle  block"  data  from  the  computer  scheduling  package,  Bus-Sched.  The  file 
created  by  this  software  is  integrated  with  the  APC  data  to  reference  location. 
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Software  functions  of  the  stationary  computer  include: 

*  validation  checks  against  expected  behavior  on  each  instrumented  vehicle; 

*  appending  route  numbers  to  the  data; 

*  appending  vehicle  assignment  information; 

*  appending  run  numbers. 

The  software  is  being  developed  by  the  joint  efforts  of  Kitchener  and 
Mississauga  Transit  properties  with  the  assistance  of  Systemware  Inc.  and  Sigma 
Star  Corporation,  both  of  Toronto.  The  software  is  100%  funded  by  the  Province 
of  Ontario.  All  source  code  will  be  supplied  to  the  properties  upon  completion 
of  the  software  development.  Planners  perceive  the  software  as  easy  and 
inexpensive  to  update  as  it  is  written  in  Fortran-77. 


REPORTS 


Kitchener  expects  the  APC  system  to  produce  the  following  reports: 
LOADING  PROFILES  TIME  PERFORMANCE 


running  times 
layover  time 
percent  on  time 
minutes  early/late 
schedule  adherence 
headway  distributions 
dwell  times 


*  average  passenger  loads 

*  maximum  passenger  loads 

*  load/capacity 

*  route  prof i les 

*  maximum  load  points 

*  boardings  by  stop 

*  al ighti ngs  by  stop 

PERFORMANCE  INDICATORS 

*  passengers  per  hour 

*  passengers  per  Kilometre 

*  boardings  per  hour 

*  revenue/cost  ratios 

*  deficit  per  passenger 

*  cost  per  passenger 

This  information  will  be  made  available  for  system  totals,  route  level,  driver 
run,  bus  trip,  route  segment  and  bus  stops;  and  will  cover  time  periods  ranging 
from  15  minute  periods  to  monthly  and  quarterly  reports.  Reports  will  be 
presented  both  routinely  and  on  demand  in  tabular  format.  Graphic  capability 
will  be  added  at  a  later  date.  Kitchener's  APC  system  will  not  have  the 
capability  to  integrate  APC  data  with  other  data  (ie.  survey  data,  etc.). 
Additional  software  or  a  commercial  data  retrieval  package  would  be  required  to 
perform  this  task.  However,  the  APC  data  could  be  used  in  conjunction  with 
surveys  to  establish  sample  rates,  population  sizes,  etc. 


APC  IMPACTS  ON  CURRENT  OPERATIONS 

As  the  APCs  have  not  yet  been  implemented  at  Kitchener,  the  impacts  cannot 
realistically  be  assessed.  The  current  data  collection  techniques  used  at 
Kitchener  involve  annual  on/off  surveys  for  all  routes  (100%  sample  of  all  runs 
and  trips)  for  a  typical  weekday  using  15-20  ride  checkers.  Interestingly,  this 
method  is  considered  very  reliable  and  accurate  (verified  by  farebox  revenues), 
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yet  Kitchener  planners  believe  the  APC  technique  will  be  an  improvement  over 
manual  methods. 


APC  ACQUISITION  AND  FUNDING  SOURCE 

The  APCs  were  acquired  through  a  tender  and  bid  process.  Three  bids  were 
received.  The  hardware  was  75%  funded  by  the  Province  of  Ontario  and  25%  by  the 
property.    The  software  was  funded  100%  by  the  Province. 


COSTS  OF  THE  APC  SYSTEM 

Note:    all  costs  quoted  are  in  Canadian  funds  as  of  August,  1984 
CAPITAL  COSTS 

*Counting  Sensors  $  18,413  (for  20  buses) 

*Microprocessor  $  34,092  (for  20  buses) 

Transfer  Device  $   1,150  (one  device) 

**Stationary  Computer  $189,000  (see  Section  B.6  for  details) 


*  Installation  costs  not  available 

**The  stationary  computer  was  purchased  over  a  year  prior  to  the  acquisition  of 
APCs  and  is  used  for  several  other  functions  in  addition  to  APCs. 


OPERATING  COSTS 

APC  system  is  maintained  by  supplier 

Counting  Sensors 
Microprocessor 
Transfer  Device 

All  other  expenses  unknown 


2  year  warranty 
$   1 ,490  per  year 
$      150  per  year 
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3.11   Mississauga  Transit 

Interview  with  Norman  Dodd,  Manager  Transit  Planning,  Mississauga  Transit, 
Ontario,  Canada 


Mississauga  has  recently  purchased  an  APC  system  consisting  of  counting  units 
and  microprocessors  for  thirty  buses  (twenty  40  foot  and  ten  60  foot  buses). 
The  hardware  will  be  installed  in  April,  1985.  The  software  will  be  developed  by 
the  joint  efforts  of  Mi ssi ssauga ' s  computer  staff  and  personnel  from  Systemware, 
an  Ontario  software  firm.  Systemware' s  consulting  fee  will  be  reduced  in 
exchange  for  the  use  of  Mi ssi ssauga ' s  mainframe  computer.  Software  costs  to  the 
property  are  also  lessened  by  splitting  25%  of  the  costs  with  Kitchener  Transit. 

In  general,  Mississauga  Transit  will  use  the  APC  data  to: 

*  create,  evaluate  and  adjust  schedules  and  run  times 

*  plan  and  justify  route  changes 

*  evaluate  marketing  strategies 

*  estimate  expected  revenue 

*  determine  fleet  needs 

*  provide  schedule  adherence  data 

*  determine  location  of  bus  shelters 

*  provide  transit  trip  generation  data 

*  provide  information  on  terminal  passengers 
(shopping  centers,  subways,  Government 

rail  commuter  train  service  evaluations,  etc.) 

*  obtain  performance  indicator  statistics 

*  calculate  revenue/cost  ratio 

*  conduct  five-year  forecasting  studies 

As  this  property  has  yet  to  implement  an  APC  system,  this  summary  examines 
Mi ssi ssauga ' s  plans  for  future  implementation  including  the  types  of  reports  it 
expects  the  system  to  produce. 

EVALUATION  OF  MISSISSAUGA  TRANSIT'S  APC  SYSTEM 

COUNTING  SENSORS 

Mississauga  Transit  has  purchased  London  Mat  treadle  mats  to  count  passengers. 
The  mats  will  be  installed  by  Ontario  Bus  Industries,  a  Mississauga  company. 
The  mats  will  be  placed  on  two  steps  with  splits  for  two  streams  at  all  doors. 
The  choice  of  mats  over  beams  was  based  on  the  experiences  of  Ottawa  (beams)  and 
Toronto  (mats)  Transit  Commissions. 

ON-BOARD  MICROPROCESSOR 

APC  Industries  of  London,  Ontario,  a  subsidiary  company  of  London  Mat 
Industries,  manufactured  the  microprocessor.  This  unit  time  tags  and  date  tags 
the  data,  records  an  odometer  reading,  accumulates  passenger  counts  (boardings 
and  alightings),  and  records  dwell  time  and  door  opening  and  closing.  The  door 
opening  activates  data  input.  When  the  memory  space  is  filled,  a  flag  indicates 
this  event  to  identify  when  and  where  data  were  lost. 
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LOCATION  REFERENCING  METHOD 


Mississauga  will  use  a  computer-generated  comparison  of  APC  odometer  reading  to 
stop  by  stop  distance  files  to  reference  location  of  data  input. 


Section  B.4:  DATA  STORAGE 

The  microprocessor  uses  a  solid  state  memory  device  to  store  APC  data.  The 
storage  capacity  is  16K  bytes. 


DATA  TRANSFER 

Mississauga  plans  to  use  an  automated  retrieval  system  to  transfer  data  from  the 
bus  to  a  stationary  computer.  The  method  will  be  a  cable  data  retrieval  system 
located  at  the  fueling  island.  Transfer  should  be  completed  within  60  seconds. 
Data  will  be  passed  through  a  hand  wired  cable  to  the  host  computer  once  each  day 
as  the  bus  is  fueled.    The  cable  will  be  made  in-house  by  Mississauga  Transit. 


STATIONARY  CPU  AND  SOFTWARE 

The  host  CPU  is  a  VAX  11/780.  For  APCs  there  will  be  one  terminal  in  the  fueling 
area  and  one  in  the  Planning  Department.  An  interactive  program  will  transfer 
the  data  from  the  fueling  area  to  the  stationary  computer.  The  VAX  was  not 
purchased  for  use  with  the  APCs  and  it  is  used  for  a  number  of  other  data 
processing  tasks. 

The  software  will  be  developed  as  a  joint  effort  between  Mi ssi ssauga' s  computer 
technicians  and  personnel  from  Systemware.  In  addition  to  creating  data  files 
and  formatting  APC  data  into  reports,  the  software  will  serve  the  following 
functions: 


*  validation  checks  against  expected 

*  append  route  numbers  to  the  data; 

*  append  bus  stop  numbers  (replacing 
location) ; 

*  append  vehicle  assignment; 

*  append  run  number. 


behavior  for  each  instrumented  vehicle; 
'distance'  measurement  with  'true' 


In  addition  to  the  files  necessary  to  perform  these  functions,  other  information 
which  must  be  input  into  the  processing  routines  are  any  exceptional  conditions 
such  as  bus  change  offs,  short  turns,  schedule  changes,  etc. 


REPORTS 

The  reports  Mississauga  expects  its  APC  system  to  produce  include  all  passenger 
loading  profiles,  time  performance,  and  system  performance  indicators  specified 
in  the  survey.  Mississauga  has  specified  that  these  data  be  available  for  the 
system,  route,  bus  trip,  route  segment,  and  bus  stop  levels.  Cordon  area  and 
screenline  crossings  have  also  been  specified.  Monthly  totals,  totals  for 
weekday,  Saturday  and  Sunday,  time  periods,  and  15  minute  periods  during  peak 
traffic  hours  should  be  produced.  Both  tabular  and  graphic  (including  color) 
formats  will  be  available  periodically  and  on-demand. 
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Other  information  needed  to  produce  these  reports  include  a  data  bank  containing 
stop-to-stop  and  route  distances,  mi ni -schedul er  files,  and  bus  data  (see 
STATIONARY  CPU  section). 


APC  IMPACTS  ON  CURRENT  OPERATIONS 

Current  data  collection  activities  at  Mississauga  include  the  following: 

*  bi-annual  screen! ine  count  program 

*  standing  counts  as  required  (usually  one  day  only) 

*  on/off  counts  as  required  by  route 

*  bi-annual  total  system  on/off  survey 

*  waybill  data  (driver  counts  of  revenue  and  transfer  passengers)  by  route 
(APC  will  check  these  data) 

Mississauga  expects  APCs  to  reduce  field  staff  work,  including  screenline  counts 
of  passengers  and  to  provide  pre-signup  data  for  route  review  studies  that  might 
not  otherwise  be  collected.  Also,  the  property  expects  APCs  to  probably 
increase  confidence  in  the  data  used  for  route  reviews. 

Future  plans  are  sketchy  as  yet  but  the  property  does  not  plan  to  equip  more  than 
25%  of  the  fleet  and  will  consider  the  use  of  microwave  signposts  in  the  future. 


APC  ACQUISITION  AND  FUNDING  SOURCE 

The  APC  hardware  was  tendered  and  the  contractor  was  chosen  on  four  criteria: 

*  lowest  price 

*  qualifications 

*  proximity  in  case  of  problems,  spares,  etc. 

*  that  counting  algorithms  were  compatible  with  step  mat  sensors 

A  one  year  warranty  on  all  hardware  was  required.  The  acquisition  was  funded  75% 
by  the  Province  of  Ontario  and  25%  by  the  property.  25%  of  the  software  cost  was 
split  with  Kitchener  Transit  in  Ontario. 

COSTS  OF  THE  APC  SYSTEM 
On-Board  Hardware: 

Total  Cost:  $3 ,700-$5 , 300  per  articulated  bus 

$2,740-$4,110  per  40'  GMC 
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3.12  Toronto  Transit  Commission 

Interview  with  Rick  Thompson,  Design  Engineer,  Plant  Department,  Toronto 
Transit  Commission,  Ontario 


Toronto's  APC  experience  began  in  1978  as  part  of  an  AVM  test  system  (Automatic 
Vehicle  Monitoring  System).  The  project  involved  equipping  100  buses  with  AVM 
and  passenger  counting  hardware.  In  1981,  the  property  discontinued  using  the 
passenger  counters  but  continued  to  operate  the  AVM  system  for  real-time  vehicle 
monitoring.  An  additional  150  buses  were  equipped  with  AVM  hardware  in  1982  and 
the  system  became  fully  operational  at  one  division  in  September,  1984,  Toronto 
is  presently  developing  a  plan  for  city-wide  implementation  of  the  AVM  system. 

Accuracy  and  reliability  of  the  APCs  were  the  two  major  considerations  in 
determining  the  viability  of  the  passenger  counting  system.  The  original  100 
buses  were  equipped  with  APCs  custom  made  by  Transduction  Ltd.  This  company  no 
longer  manufactures  or  supports  this  product.  After  extensive  testing  of  the 
hardware,  the  property  determined  that  the  accuracy  of  the  data  did  not  meet 
specified  accuracy  levels,  particularly  at  high  use  stops  (six  or  more 
passengers  boarding  or  alighting  at  one  stop).  For  this  reason,  the  APC  portion 
of  the  AVM  system  was  discontinued. 

Due  to  the  fact  that  the  APC  project  was  never  fully  operational  (since  the 
required  accuracy  was  never  met),  the  passenger  count  data  were  used  in  real- 
time monitoring  only.  The  real-time  monitoring  function  of  the  AVM  system  has 
taken  priority  over  the  off-line  information  function  of  the  AVM  system. 

APC-related  problems  found  during  testing  were  associated  mainly  with  activity 
at  high  use  stops.  For  this  reason,  the  property  has  decided  to  implement  APCs 
at  off-peak  times  (weekends).  At  the  request  of  the  planning  department,  150 
buses  will  be  equipped  with  passenger  counters.  The  property  is  now  in  the 
process  of  writing  specifications  to  purchase  the  APC  units.  This  project  will 
operate  separately  from  the  AVM  system. 


EVALUATION  OF  TORONTO  TRANSIT  COMMISSION'S  APC  SYSTEM 
COUNTING  SENSORS 

Infrared  beams,  manufactured  by  Transduction  Ltd.,  were  used  in  the  initial  APC 
installation  on  100  buses.  The  reliability  of  the  hardware  and  the  accuracy  of 
the  data  were  too  low  to  meet  the  property's  specified  criteria. 
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Specified  accuracy  levels  for  both  boardings  and  alightings  were: 


Error 


Percent  of  the 
Time 


For  1-5  people 


0 

±1 
±2 


70 
95 
99 


For  6-10  people 


0 
±1 
±2 


40 
90 
95 


For  11  or  more 


within  10% 


90%  of  the  time 


Testing  generally  showed  acceptable  accuracy  levels  for  1-5  people  boarding  or 
alighting  at  one  stop,  but  six  or  more  people  at  one  stop  could  not  be  accurately 
counted  within  these  parameters  using  infrared  sensors. 

In  1982,  the  property  began  experimenting  with  treadle  mats  manufactured  by 
London  Mat.  Although  the  mats  proved  to  be  more  accurate  than  the  beams, 
accuracy  at  high  use  stops  was  unacceptable  using  the  mats  as  well.  At  present, 
the  property  has  exhausted  all  testing  with  the  mats  and  plans  to  write 
specifications  to  equip  150  buses  with  APCs.  This  system  will  be  used  to  obtain 
off-peak  samples  on  weekends  and  evenings  only. 

ON-BOARD  MICROPROCESSOR 

For  the  initial  testing  (using  the  beams),  the  microprocessor  in  the  AVM  unit  on 
the  bus  accumulated  count  data  and  a  modem  transmitted  these  data  through  the 
radio  to  the  central  computer.  The  AVM  units  were  manufactured  by  Unified 
Technologies  Inc.  (no  longer  in  business).  The  microprocessor  used  in 
conjunction  with  testing  of  the  mats  was  supplied  by  London  Mat  and  designed  by 
Dynamic  Controls.  These  units  were  interfaced  with  the  AVM  units  for  radio 
transmission  to  the  central  computer. 

The  passenger  counting  function  of  the  system  was  event-driven.  That  is, 
passenger  counting  occurred  only  when  bus  doors  were  open.  Events  recorded  by 
the  APCs  were:  door  opening  and  closing,  distance  between  stops,  and  signpost 
codes.  None  of  the  APC  buses  were  lift-equipped.  The  AVM  unit  contains  a  clock 
to  detect  time,  a  separate  odometer  (a  sensor  attached  to  the  right  front  wheel) 
and  an  algorithm  to  interpret  signpost  codes. 

The  equipment  was  maintained  in-house.  The  Transportation  Department 
identified  passenger  counting  problems  from  the  screen  (in  real-time)  and  passed 
this  information  on  to  the  Maintenance  Department. 


LOCATION  REFERENCING  METHOD 

Toronto  uses  sharp  signposts  at  precise  locations  at  specific  points  along 
routes.  These  units  are  microwave  transmitters.  When  a  vehicle  receives  a 
signpost  transmission,  the  AVM  unit  will  reset  the  AVM  odometer  to  zero.  About 
45  signposts  are  installed  with  an  average  of  about  2-3  signposts  per  route. 
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Generally,  the  signposts  were  placed  at  three  mile  intervals  or  at  branch 
locations.   At  least  one  signpost  reading  is  obtained  per  bus  trip. 

The  signposts  are  A.C.  powered  (tap  into  the  city  power  supply).  They  have  no 
notable  maintenance  requirements  and  their  performance  is  considered 
satisfactory.  The  signposts  were  designed  by  Toronto  Transit  Commission  and 
manufactured  by  Electrocomm,  a  local  firm. 


DATA  STORAGE 

Since  the  AVM  system  transfers  data  in  real-time,  there  is  no  need  for  on-board 
storage  of  the  data.  The  AVM  units  do  contain  short-term  solid  state  memory  for 
storage  prior  to  transfer. 


DATA  TRANSFER 

As  part  of  the  AVM  system,  the  data  are  transferred  to  the  central  computer  in 
real-time  through  designated  radio  channels.  Every  six  seconds,  each  bus  is 
polled  by  the  program  in  the  central  computer.  This  information  is  displayed  on 
screens  for  use  mainly  by  the  Transportation  Department. 


STATIONARY  CPU  AND  SOFTWARE 

With  the  AVM  system,  a  Data  General  Nova  minicomputer  is  used  to  process  the 
data.    This  unit  was  purchased  with  the  AVM  system  and  it  is  a  dedicated  unit. 

Although  report  software  was  developed  for  use  in  off-line  reporting  of  the 
passenger  count  data,  it  was  never  used  due  to  the  inaccuracy  of  the  data.  All 
software  related  to  the  AVM  system  and  report  software  was  developed  in-house  by 
computer  services  technicians.  At  present,  an  automated  mini schedul ing  system, 
booking  information,  etc.  are  on  file  and  are  incorporated  with  the  AVM  data 
during  data  processing. 


Although  the  exact  arrangements  have  not  yet  been  made,  it  appears  likely  that 
the  APC  data  generated  from  the  new  counting  units  will  be  processed  on  the 
property's  IBM  mainframe.  There  is  report  generating  software  available  on  the 
IBM.  This  software  is  presently  used  to  produce  reports  from  manual  counts. 
This  report  software  will  be  used  with  the  new  APC  system. 


REPORTS 

AVM  reports  have  been  available  since  the  system  became  fully  operational  in 
September,  1984.   APC  reports  were  not  generated  from  Toronto's  AVM  system. 


APC  IMPACTS  ON  CURRENT  OPERATIONS 

The  APC  system  was  initially  installed  as  part  of  an  AVM  project.  The  real-time 
monitoring  function  took  priority  over  the  off-line  information  system.  Since 
the  passenger  counters  did  not  pass  the  test  for  acceptable  accuracy,  they  were 
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never  used  to  collect  data  for  off-line  reporting.  For  this  reason,  the  APCs 
have  not  had  any  impacts  on  current  operations. 


APC  ACQUISITION  AND  FUNDING  SOURCE 

Toronto  used  an  RFP  process  to  select  a  supplier  for  its  AVM  system.  The  project 
was  funded  75%  by  the  Province  of  Ontario  and  25%  by  the  Metropolitan 
Government. 

COSTS  OF  THE  APC  SYSTEM 
CAPITAL  COSTS 

For  AVM:  $5000  per  vehicle  for  total  hardware  for 


AVM  (includes  APC)  in  1978. 


Instal lation 
Signpost  receiver: 


2  person  days  each  unit 
$  350  per  unit 


OPERATING  COSTS 


Maintenance: 


.2  FTE 
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3.13    Southern  California  Rapid  Transit  District  (SCRTD) 

Interview  with  Louis  Cherene,  Senior  Planner,  SCRTD,  Los  Angeles,  California 

SCRTD' s  passenger  counting  system,  first  implemented  in  1980  as  a  demonstration 
project  funded  by  UMTA,  is  a  prototype  system  intended  as  an  ongoing  APC 
evaluation  program.  This  APC  system  functions  in  real-time  for  screen-oriented 
monitoring  (AVM  or  "Automatic  Vehicle  Monitoring")  and  off-line  for  report 
generation.  The  APCs  are  used  to  obtain  information,  both  real-time  and  off- 
line, on  four  of  the  200  routes.  Off-line,  APC  data  are  used  primarily  for 
scheduling;  on-line,  the  APC  system  monitors  vehicles  for  performance  and 
emergency  response. 

SCRTD's  APC  system  was  fully  operational  in  1982.  After  that  year,  interest  in 
the  system  waned  and  the  hardware  and  software  deteriorated.  SCRTD  identifies 
the  problem  both  organizational  and  hardware-related.  Other  transit  functions 
have  taken  priority  over  data  collection  activities.  Providing  bus  service  for 
the  Special  Olympics  is  one  example  of  a  non-APC  priority.  Also,  maintenance  of 
APCs  has  come  second  to  maintenance  of  the  voice  radio  system  which  operates 
through  a  separate  radio  channel  from  the  AVM.  As  a  result,  about  30%  of  the 
sensors  are  presently  malfunctioning.  Many  of  the  signpost  batteries  need  to  be 
replaced  as  they  approach  their  five  year  shelf  life. 

Due  to  these  and  other  problems  with  the  APC  system,  there  is  presently  very 
little  confidence  in  APC  data  at  SCRTD.  APC  data  are  available  only  for  about 
40%  of  the  trips.  Occasionally,  this  percent  will  be  as  high  as  70%  on 
individual  lines.  For  this  reason,  SCRTD  continues  to  employ  34  full  time 
salaried  ride  checkers.  The  APC  time  performance  data  are  compared  with 
manually  collected  data  for  accuracy  and  to  distribute  the  checker  counts  along 
routes  and  route  segments. 

In  response  to  the  many  and  varied  problems  encountered  with  APCs  at  SCRTD,  the 
property  has  hired  a  specialist  to  evaluate  and  upgrade  the  APC  system  as  part 
of  a  new  Transit  Radio  System  (TRS).  Funds  for  the  project  will  be  apportioned 
for  hardware  improvements  and  software  development.  SCRTD  is  now  in  the  process 
of  evaluating  and  recommending  needed  improvements  to  the  AVM  subsystem.  Plans 
for  the  future  include  equipping  100%  of  the  fleet  with  new  radio  transmitters 
as  part  of  an  improvement  in  both  the  TRS  and  the  AVM  systems  and  the  improvement 
of  the  existing  service  analysis  software  developed  by  Mul ti systems ,  Inc. 


EVALUATION  OF  SCRTD'S  APC  SYSTEM 
COUNTING  SENSORS 

At  SCRTD,  200  buses  are  equipped  with  APCs.  Of  these,  17  are  articulated.  Ten- 
to-twenty  buses  are  equipped  with  infrared  beams  and  the  rest  contain  mats.  The 
mats  were  made  by  London  Mat  Industries;  the  beams  were  made  by  Red  Pine, 

Common  problems  associated  with  the  sensors  are  damage  to  the  mats  caused  by 
wheelchairs  and  during  repair  of  wheelchair  lifts,  and  beam  wires  being  cut  when 
other  maintenance  of  the  bus  is  performed.  Due  to  such  conditions,  about  20-30% 
of  the  data  are  discarded  during  processing  routines  due  to  bad  or  inconsistent 
counts.  An  additional  consideration  is  the  on-off  discrepancy  common  to  APC 
counts.    At  SCRTD,  on-off  discrepancy  is  resolved  to  5%  of  the  data.    That  is, 
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when  the  discrepancy  between  boardings  and  alightings  exceed  5%  of  the  counts 
for  a  particular  run,  the  data  for  that  run  are  discarded.  This  percentage  is 
low  in  comparison  to  other  properties,  most  of  which  compensate  for  discrepancy 
up  to  10-15%  of  the  data. 


ON-BOARD  MICROPROCESSOR 

The  microprocessor  was  supplied  by  AVM,  Inc.  The  manufacturer  of  the  unit  was 
not  known.  The  microprocessing  unit  used  at  SCRTD  accumulates  counts  and 
location  data;  but  it  does  not  write  records  to  tape  or  store  data  on-board  the 
bus.    These  functions  are  performed  during  data  transfer  (see  DATA  TRANSFER). 

The  microprocessor  contains  a  clock  which  time  tags  data  according  to  a  24  hour 
clock,  an  odometer  to  register  distance  and  a  signpost  signal  receiver. 


LOCATION  REFERENCING  METHOD 

SCRTD  uses  signpost  readings  to  reference  location  of  data  input.  A  total  of 
900  signposts  are  presently  installed.  Of  these,  400  are  located  on  the  routes 
currently  surveyed  by  APCs.  The  others  were  left  in  place  to  locate  off-route 
vehicles  and  random  route  vehicles.  SCRTD  pays  the  City  of  Los  Angeles  $25,000 
per  year  for  the  privalege  of  hanging  these  signposts. 

These  signposts,  manufactured  by  AVM,  Inc.,  are  broad  beam,  battery  powered 
signposts.  They  function  by  transmitting  coded  signals  within  an  800  foot 
radius.  The  on-board  receiver  accepts  the  three  strongest  signals.  The 
signposts  are  positioned  approximately  on  every  other  block  and  there  are  about 
8  signposts  per  mile  on  the  four  main  routes  in  the  system.  The  only  problem 
with  the  hardware  is  that  the  batteries  need  to  be  replaced  after  five  years. 
Also,  it  is  necessary  to  reset  the  codes  after  batteries  are  replaced. 


DATA  STORAGE 

Data  are  not  stored  on-board  the  bus  (see  DATA  TRANSFER). 
DATA  TRANSFER 

Data  transfer  is  performed  by  an  interactive  computer  program  which  communicates 
with  the  ARC  buses  via  a  special  radio  channel.  An  AVM  program  in  the  DEC  11/60 
minicomputer  taps  into  the  radio  computer  and  operates  two  polling  base 
stations.  The  DEC  contains  two  disk  drives  and  a  tape  drive.  Every  40  seconds, 
data  are  transmitted  from  the  microprocessor  on-board  the  bus  to  the  11/60  and 
processed.  These  data  are  displayed  on  screens  for  real-time  monitoring  and,  at 
the  same  time,  written  on  disk. 

Every  morning,  the  data  stored  on  disks  are  processed  and  written  on  magnetic 
tape.  These  tapes  are  then  converted  and  read  onto  an  IBM  3083  system  for 
service  analysis.    These  data  include: 
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*  line  identification 

*  date 

*  direction  of  bus 

*  headers  of  time  points 

*  trip  summary  (which  labels  the  bus  #,  run  #,  trip  #,  branch,  bus  type, 
number  of  boardings  and  alightings,  etc.) 

*  time  points  which  are  numbered  from  1  to  19  including  schedule  data 
(minutes  early/late),  number  of  miles  past  time  point  that  signpost  signal 
was  received,  cumulative  boadings  and  alightings,  maximum  load,  etc. 

STATIONARY  CPU  AND  SOFTWARE 

The  stationary  computer  is  located  in  the  central  transit  station.  This  is  the 
DEC  11/60  minicomputer  purchased  specifically  for  use  with  the  AVM  system.  The 
DEC  is  a  dedicated  unit  with  consoles  for  use  in  real-time  monitoring. 

Data  file  creation  and  report  generation  take  place  in  the  DEC.  Every  week,  a 
new  tape  is  mounted  and  the  old  tape  is  stored  in  the  tape  library.  Although 
data  for  a  full  month  could  be  stored  on  one  tape,  tapes  are  replaced  weekly  in 
order  to  more  effectively  monitor  the  system.  Due  to  library  space  constraints 
and  to  the  huge  volume  of  ARC  data  collected,  these  tapes  are  stored  for  one 
quarter  and  then  moved  to  warehouse  storage. 

The  software  used  to  process  the  ARC  data  for  service  analysis  (off-line)  is 
located  in  an  IBM  mainframe.  Mul ti systems ,  Inc.  has  been  contracted  to  develop 
software  which  will  accurately  generate  and  format  data  files  and  reports. 

RERORTS 

At  present,  daily  and  weekly  reports  are  produced  by  the  ARC  system.  Daily 
reports  indicate  whether  the  data  are  good,  identify  hardware  failures  and  other 
equipment  problems,  and  produce  the  summaries  described  above  (see  DATA 
TRANSFER).  As  noted  above,  use  of  ARC  data  for  service  analysis  has  been  limited 
and  these  reports  are  not  routinely  produced  by  SCRTD's  ARC  system.  Efforts  are 
underway  to  use  service  analysis  software  and  ARC  data  to  update  schedules  on 
two  lines. 


ARC  IMRACTS  ON  CURRENT  ORERATIONS 

The  impacts  of  ARCs  are  primarily  felt  by  Telecommunications  and  vehicle 
maintenance  personnel.  For  example,  because  the  AVM  system  competes  with  the 
voice  radio  for  transmission  of  information,  the  ARCs  come  into  conflict  with 
the  service  monitoring  and  vehicle  response  functions  for  which 
Telecommunications  personnel  are  primarily  responsible.  Special  efforts  were 
required  to  assign  ARC-equipped  buses  to  monitored  lines.  As  a  result,  ARC  data 
has  been  spotty  over  an  extended  period  of  time.  These  organizational  problems 
are  cited  as  the  greatest  impediment  to  the  success  of  SCRTD's  ARC  program. 


SCRTD  ASSESSMENT  AND  SUGGESTIONS 

Many  of  the  difficulties  encountered  at  SCRTD  directly  relate  to  the  integration 
of  the  ARCs  with  a  real-time  monitoring  system.  This  problem  is  analogous  to  the 
more  common  problem  with  data  transfer  using  security  guards.    When  ARCs  come 
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into  conflict  with  traditional  transit  functions  which  are  essential  to  every 
day  operations,  the  functionality  and  success  of  the  APC  system  are  threatened. 
In  the  case  of  SCRTD,  the  APC  system  was  neglected  over  the  years.  As  a  result, 
a  large  investment  in  time  and  money  resources  is  now  being  made  to  restore  the 
system  to  its  former  level  of  functioning. 

The  primary  purpose  of  the  APC  Prototype  operated  by  SCRTD  is  to  ascertain  the 
technical  feasibility  of  such  a  system  and  to  identify  its  value  for  both  real 
time  control  of  vehicle  service  and  off-line  analysis  of  service  data.  The 
present  system  is  providing  Telecommunications,  Operations,  Planning,  and 
Scheduling  personnel  with  ample  experience  to  intelligently  evaluate 
alternative  features  of  the  new  Transit  Radio  System. 


APC  ACQUISITION  AND  FUNDING  SOURCE 

SCRTD' s  APC  system  was  funded  by  an  UMTA  section  6  grant  as  a  demonstration 
project  in  1980.  An  RFP  process  was  used  and  the  contract  was  awarded  to  AVM, 
Inc.,  the  system  integrator. 


COSTS  OF  THE  APC  SYSTEM 

The  costs  of  SCRTD' s  APC  project  were  not  available  at  the  time  of  the 
Interview. 


83 


Chapter  Four 
Assessment  Of  APC  Techniques 


Like  many  recent  innovations,  automated  data  collection  techniques  have 
introduced  a  wide  range  of  possibilities  for  gaining  knowledge  about  operational 
systems.  Ideally,  the  types  and  volumes  of  data  APCs  make  available  to  transit 
agencies  form  the  basis  for  more  informed  decisions  and,  consequently, 
contribute  to  increased  operational  efficiency  and  improved  service  to  the 
publ ic. 

A  variety  of  factors  come  into  play  in  the  assessment  of  APCs  in  light  of  this 
ideal.  For  large  transit  agencies,  the  relative  cost  of  APCs  when  compared  to 
manual  methods  may  be  the  deciding  factor.  For  small  agencies,  the  benefits  of 
APCs  are  seen  chiefly  in  the  types  and  amounts  of  data  the  systems  provide.  For 
all  transit  agencies,  the  intended  uses  of  APC  data  should  be  identified  in  the 
first  phase  of  an  evaluation  of  APCs.  This  identification  of  data  needs  is  also 
a  critical  step  in  writing  specifications  for  an  APC  system. 

For  these  reasons,  this  assessment  begins  with  a  discussion  of  intended  uses  of 
APC  data.  This  is  followed  by  an  analysis  of  APC  system  components,  including 
accuracy  and  reliability  issues.  The  benefits  of  APCs  are  discussed  next  and 
reports  are  included  which  illustrate  the  capabilities  of  existing  systems. 
Costs  of  APCS  are  the  topic  of  discussion  in  the  next  section,  followed  by  a 
perscription  for  APC  system  implementation.  The  issues  and  concerns  revealed  in 
these  discussions  are  summarized  in  the  final  section  of  the  chapter. 


4.1    Intended  Uses  Of  Data 

Agencies  need  to  evaluate  their  data  needs  and  identify  intended  uses  of  the 
data  before  deciding  to  implement  an  APC  project.  This  requirement  applies  both 
to  agencies  studying  the  feasibility  of  APCs  and  to  agencies  planning  a 
conversion  to  automated  techniques.  The  evaluation  of  data  needs  is  especially 
important  for  small  transit  agencies  since  the  cost-effectiveness  of  APCs  is 
less  precisely  defined  for  small  properties  than  for  large  properties.  This 
evaluation  should  consider  the  following: 

(1)  the  adequacy  of  current  methods  in  collecting  needed  data  (This 
consideration  implies  an  evaluation  of  current  methods  in  terms  of  their 
effectiveness  in  providing  a  sufficiently  large  sample  from  which  to  make 
inferences  about  the  true  performance  of  the  system.); 

(2)  data  presently  collected  manually  that  might  be  obtained  more  efficiently 
using  automated  data  collection  methods  (This  issue  implies  that  present 
methods  be  evaluated  in  terms  of  effectiveness,  benefits,  and  costs;  and 
that  a  comparison  be  made  between  present  methods  and  automated 
techni ques) ;  and 

(3)  classes  of  data  needed  but  not  presently  collected;  the  purposes  for 
obtaining  this  information  now;  and  the  objectives  this  additional 
information  is  likely  to  serve.  (Desired  accuracy  level  and  sample  size  are 
a  function  of  the  uses  to  which  data  will  be  put.  It  is  thus  important  to 
consider  the  reasons  for  needing  particular  information  in  deciding 
whether  or  not  the  data  should  be  collected,  how  much  to  collect,  and  what 
is  the  best  method  to  use.) 


85 


The  intended  uses  of  the  APC  data  by  current  user  properties  are  displayed  in 
Table  4.1.  The  uses  of  data  by  APC-AVM  properties  (Toronto  and  Los  Angeles)  are 
not  included  in  this  table  since  the  priority  uses  of  these  systems  are  vehicle 
monitoring  and  emergency  response  rather  than  off-line  reporting.  London 
Transit  was  also  excluded  since  this  APC  application  consists  solely  of  treadle 
mats;  data  recording  and  analyses  are  performed  manually. 

Because  all  of  the  agencies  interviewed  are  now  undertaking  APC  system 
modifications,  intended  rather  than  present  uses  of  APC  data  from  upgraded  or 
fully  installed  systems  are  listed  in  Table  4.1.  All  of  those  interviewed  plan 
to  use  the  data  obtained  by  the  APC  systems  for  scheduling  and  route  planning 
activities;  and  all  of  the  U.S.  properties  plan  to  use  APC  data  for  Section  15 
reporting.  Half  of  those  interviewed  plan  to  use  the  data  to:  evaluate 
marketing  strategies;  determine  fleet  needs;  and  determine  the  location  of  bus 
stop  facilities.  None  of  the  U.S.  properties  plan  to  use  APC  data  to  estimate 
expected  revenue  or  monitor  driver  performance. 

The  "other"  uses  of  data  included  on  this  table  were  not  part  of  the  original 
survey,  but  were  mentioned  by  some  agencies  during  the  interviews.  It  is  likely 
that  more  agencies  plan  to  use  APC  data  for  these  purposes. 


4.2  APC  System  Components 

APC  systems  collect  and  analyze  data  on  transit  passenger  activity,  time,  and 
location.  The  success  of  APC  systems  in  accomplishing  these  tasks  is  contingent 
on  synergism  of  three  essential  system  components:  hardware,  software  and 
personnel.  Each  of  these  components  plays  a  vital  role  in  the  quality  of 
overall  system  performance. 

4.2.1   APC  HARDWARE 

There  are  both  essential  and  optional  hardware  components  in  current  APC 
systems.    Essential  components  are: 

*  counting  sensors:  either  treadle  sensor  mats  or  infrared  beams  to  detect 
passenger  boarding  and  deboarding  activities; 

*  data  collection  units:  commonly  referred  to  as  either  system  controllers, 
PDU  (portable  data  units),  or  DCU  (data  collection  units),  to  accumulate 
and  record  counts,  time,  and  location  data  (contains  a  microprocessor, 
clock,  odometer  sensing  unit,  an  interface  board,  and  a  storage  device); 

*  a  power  supply  to  convert,  condition  and  filter  primary  bus  voltage  to  the 
data  collection  system. 

*  data  retrieval  units:  either  automatic  (radio-link,  infrared,  or  cable)  or 
manual  (cassette  or  PDU  (portable  disk  units))  devices  used  to  retrieve 
data  from  on-board  the  buses  and  transfer  to  the  stationary  computer;  and 
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Table  4.1:  Intended  Uses  Of  APC  Data 


Number  of 


Uses  Of  Data  Responses 

*  Create,  evaluate  and  adjust  schedules  and  run  times  10 

*  Plan  and  justify  route  changes  10 

*  Evaluate  marketing  strategies  5 

*  Determine  fleet  needs  5 

*  Determine  location  of  bus  stop  facilities  5 

*  Prepare  Section  15  reports  5 

*  Estimate  expected  revenue  3 

*  Monitor  driver  performance  3 

*  Other: 

*  Report  on  ridership  2 

*  Respond  to  non-standard  inquiries  2 

*  Conduct  cordon/screenl ine  and/or  area  counts  2 

*  Provide  transit  trip  generation  data  2 

*  Obtain  performance  indicator  statistics  for  2 
route  group  analysis 

*  Conduct  5  year  forecasting  studies  2 


Missing  Cases:  3 

(This  information  was  not  obtained  for  Toronto, 
Los  Angeles,  or  London  Transit  Agencies) 


Notes : 

1.    Intended  rather  than  actual  use  is  included  in  this  table. 

Currently,  all  properties  are  modifying  their  APC  systems.  The 
listings  here  reflect  the  intended  use  of  data  obtained  from  new  or 
upgraded  systems. 
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*  stationary  computer:    either  a  mainframe,  minicomputer,  or  microcomputer  to 
process  APC  data  and  produce  reports. 

Optional  devices  include: 

*  door  switches:    to  monitor  or  control  counting  when  bus  doors  are  closed; 
and 

*  signposts:    to  transmit  signal  to  the  on-board  data  collection  unit  (via 
special  signpost  antennae  atop  the  bus)  to  identify  bus  location. 

The  hardware  used  in  implemented  systems  is  displayed  in  Table  4.2.  A  full 
description  of  these  devices,  their  use,  and  relative  advantages  and 
disadvantages  can  be  found  in  the  individual  case  studies  in  Chapter  Three.  To 
summarize  from  Table  4.2:  infrared  beams  are  used  more  frequently  than  treadle 
sensor  mats;  automatic  data  retrieval  is  more  common  than  manual  data  transfer; 
and  minicomputers  are  the  most  popular  size  stationary  computer. 

These  frequencies  generally  make  sense  given  the  special  considerations 
involved  in  APC  use.  Although  slightly  less  accurate  than  mats,  beams  have 
lower  initial  and  replacement  costs.  Also,  wheelchairs  and  water  infiltration 
cause  damage  to  the  mats.  The  reliability  of  the  beams  is  good  as  long  as  the 
lightheads  are  kept  free  of  heavy  dust  accumulation  and  are  properly  installed 
and  aligned.  Mats  may  be  a  better  option  on  buses  without  lifts  in  relatively 
dry  cl i mates. 

The  choice  between  automatic  and  manual  data  retrieval  depends  on  the  agency's 
resources  and  the  availability  of  staff  to  perform  the  transfer.  Automatic 
transfer  has  higher  initial  and  installation  costs;  while  manual  transfer 
involves  the  use  of  human  labor.  Manual  transfer  works  best  when  it  does  not 
interfere  with  the  routine  operations  of  the  agency.  When  data  retrieval  is  a 
second  priority  of  the  person  doing  it  (e.g.  security  guard,  driver,  etc.),  data 
transfer  is  less  reliable  since  this  is  not  this  person's  primary 
responsibility.  Manual  transfer  does  work  well  when  properly  trained, 
dependable  individuals  are  assigned  this  as  a  priority  task.  Note  that  solid 
state  memory  in  the  data  collection  unit  is  required  for  automatic  data 
retrieval . 

There  are  also  factors  to  consider  in  choice  of  specific  retrieval  method. 
Radio-link  transfer  may  require  the  use  of  a  dedicated  radio  channel;  infrared 
transfer  cannot  be  performed  if  the  bus  is  on  a  hoist  or  there  are  construction 
detours  at  the  site;  and  cable  transfer  has  yet  to  be  tested.  With  regard  to 
manual  retrieval,  both  cassette  tape  and  PDU  require  the  use  of  a  retrieval 
device.  The  principal  difference  between  these  two  manual  methods  is  that  with 
cassettes  it  may  be  neccessary  to  transfer  the  data  to  disk  for  use  on  the 
stationary  computer;  and  this  can  be  a  time-consuming  process.  At  least  one 
manufacturer  is  now  phasing  out  cassette  retrieval. 

Minicomputers  have  several  advantages  which  may  be  an  indication  of  why  they  are 
used  more  frequently  than  other  size  computers  for  APC  data  processing. 
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Table  4.2:    APC  Hardware  Used  In  Implemented  Systems 


Counting 

Sensor 

Data  Retrieval  Device 

stationary  Computer 

Beams  I 

Mats 

Automatic  I  Manual 

Mainframe    I    Mini    I  Micro 

APC  SYSTEMS 

1 

1 

1  j 

Seattle 
Ottawa 

1 

X  1 

X 

1  PDU  + 
1  Cassette 
Radio  1 

1      VAX  1 
1      VAX  t 

Kfi  1  ^5  nifi  7r)n 

X  1 

1  Cassette 

PRIME    1      IBM*  1 

1  nnrinn 

X 

None  1 

None    1  1 

Va/t  nrl en V* 
n  1  1  lu  our 

X  1 

Radio  1 

1  MODCOMpj 

Calgary 

X  1 

1  PDU 

IBM    1  1 

Portland 

X  1 

Infrared  j 

IBM    1  1 

Col umbus 

X  1 

1  Cassette 

PRIME    1              1  IBM* 

Chicago 

X  1 

1  Cassette 

UNIVAC    1  1 

Kitchener 

X 

Cable  1 

1      VAX  1 

Mi  ssi  ssauga 

X 

Cable  1 

1      VAX  1 

AVM-APC  SYSTEMS  1 

Toronto 

X  1 

X 

Radio  1 

IBM    1  1 

Los  Angeles 

X  1 

X 

Radio  1 

1      DEC  1 

Total 

9  1 

6 

7    1  5 

5    17       1  1 

Notes : 

1.  Kalamazoo  plans  to  purchase  an  IBM  PC  AT  to  process  APC  data. 

At  present,  UTA  processes  the  data  and  produces  reports  for  this  agency. 

2.  COTA  in  Columbus,  Ohio  uses  an  IBM  XT  to  generate  reports. 
Data  files  are  created  for  COTA  on  UTA's  PRIME  computer. 
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These  advantages  include: 

(1)  both  data  file  creation  and  report  generation  can  be  performed  on  the  same 
computer; 

(2)  mi nimcomputers  allow  greater  flexibility  than  mainframes  since  they  can  be 
interfaced  with  mainframes  and  micros;  and 

(3)  if  minicomputers  are  used  as  dedicated  units,  there  is  less  competition  for 
use  of  the  system,  reducing  the  impacts  of  APCs  on  other  operations. 

Whichever  device  is  selected,  choice  of  a  computer  already  in  use  with  APC 
programs  will  reduce  software  costs  by  avoiding  the  expense  of  modifications. 
Modifying  software  from  one  computer  make  to  another  comprises  a  major  portion 
of  overall  software  expense. 

In  addition  to  the  hardware  included  in  Table  4.2,  a  system  controller  is 
required  to  accumulate  and  store  data  on-board  the  bus.  This  device  is 
sometimes  referred  to  as  a  data  collection  unit  (DCU)  or  a  portable  data  unit 
(PDU).  The  system  controller  receives  and  records  the  signals  transmitted  by 
the  sensors,  the  odometer  and  the  signposts.  It  contains  a  clock  which  stamps 
the  data  when  significant  events  occur  (such  as  passengers  boarding  or  receipt 
of  a  signpost  signal ) . 

Signposts  and  door  switches  are  optional  devices  which  improve  the  accuracy  and 
reliability  of  the  data.  Door  switches  either  monitor  or  control  counts  with  bus 
doors  closed.  Signposts  transmit  a  coded  radio  signal  to  the  buses,  via  special 
antennae  atop  the  bus,  to  either  substitute  for  or  augment  odometer  readings  to 
identify  location.  This  can  be  done  in  one  of  three  ways  depending  on  the 
signpost,  system  controller  and  software  capabilities: 

(1)  upon  receipt  of  the  signal,  the  system  controller  resets  the  odometer  to 
zero;  or 

(2)  the  system  controller  records  signpost  field  entry  and  exit  points  and  the 
software  later  interpolates  between  these  points  to  calculate  location;  or 

(3)  the  system  controller  records  precise  location  of  vehicle  from  coded  radio 
signal  at  specific  locations. 

Refer  to  the  case  studies  in  Chapter  Three  for  detailed  discussions  on  these 
three  methods. 


4.2.2  APC  SOFTWARE 

Due  to  the  large  volume  of  data  generated  by  APCs  and  to  the  complexity  of 
processing  routines,  software  development  and  processing  costs  frequently 
exceed  the  expenditures  for  hardware.  In  addition,  as  with  hardware  components, 
the  cost  of  APC  software  is  a  function  of  the  level  of  detail  and  sample  size 
desired  by  the  user  property.  For  these  reasons,  special  efforts  were  made  in 
this  study  to  explore  ways  to  minimize  software  expenditures.  Separate 
processing  routines  are  required  to  perform  the  two  discrete  software  functions 
necessary  to  process  APC  data: 

(1)    data  file  creation;  and 
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(2)    report  generation. 


Of  the  two  processes,  data  file  creation  is  much  more  complex,  time  consuming, 
and  costly.  Fortran  programs  are  used  to  create  data  files.  The  first  step 
involves  merging  schedule  files  with  APC  data  to  calculate  location.  Next,  these 
data  are  validated,  edited,  sorted,  and  stored  in  files  on  either  disks  or  tapes 
or  both.  For  a  property  comparable  in  size  and  service  area  population  to  Lane 
Transit  (with  a  total  of  about  80  buses),  it  takes  about  three  days  to  create  a 
data  file  from  two  weeks  of  data  from  15  to  20  buses. 

The  second  software  function,  report  generation,  is  a  relatively  simple 
procedure.  Packaged  software,  usually  SPSS  PC  or  SAS,  is  used  to  access  APC 
data  files,  perform  analyses,  and  format  reports.  One  aspect  of  report 
generation  which  will  incur  some  cost,  although  not  a  major  one,  is  writing  the 
command  files  for  use  with  the  software.  The  cost  of  this  task  is  unknown.  The 
only  other  costs  associated  with  report  generation  are  the  computer  and  labor 
costs  of  running  the  programs.  About  one  day  per  month  is  required  in  human 
effort  to  perform  this  task. 

Table  4.3  groups  the  current  approaches  to  APC  data  processing  by  hardware  and 
software  vendor  or  supplier.  These  approaches  represent  three  software 
development  options: 

(1)  software  support  contracts; 

(2)  in-house  software  development;  and 

(3)  software  acquisition 

Software  Support  Contracts 

Many  APC  properties  have  contracted  with  private  consulting  firms  for  on-going 
software  support.  Part  or  all  of  the  data  processing  is  done  by  the  firm  using 
the  firm's  facilities.  Often,  a  consulting  firm  becomes  involved  either  in 
demonstration  projects  or  during  initial  installation  of  permanent  systems. 

Kalamazoo  Metro  (Michigan)  and  COTA  (Columbus,  Ohio)  are  two  properties  which 
have  taken  this  approach  to  data  processing.  At  Metro,  cassette  tapes  are  sent 
to  Urban  Transportation  Associates  (UTA),  a  private  consulting  firm,  once  every 
two  weeks.  Within  one  week  from  the  date  the  tapes  are  received,  UTA  sends  the 
final  reports  requested  by  Metro.  Kalamazoo  is  now  in  the  process  of  purchasing 
an  IBM  PCAT  to  process  the  data  in-house.  The  software  will  be  purchased  from 
UTA. 

Although  UTA  has  performed  similar  services  for  COTA  in  the  past,  currently  the 
report  generation  step  is  being  conducted  by  COTA  on  its  microcomputer.  COTA 
also  has  access  to  a  mainframe  which  it  plans  to  use  for  larger  jobs. 
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Table  4.3:    Hardware  and  Software  Applications 


Supplier/Vendor 


Hardware 


Software 


Properties 


Urban  Transportation 
Associates  (UTA) 


Red  Pine  Instruments 
Pachena 

2 

General  Motors 
APC  Industries 

AVM  Systems  Inc. 

Unified  Technologies  Inc, 

2 

and  Transduction  Ltd. 


UTA 


Group  Five 
In-house 
Group  Five 

In-house 
Systemware  and 
Sigma  Star 

General  Motors 

Systemware  and 
In-house 

Mul ti  systems 

In-house 


Kalamazoo 

Columbus 

Chicago 

Ottawa 

Portland 

Calgary 

Seattle 

Kitchener 

Windsor 

Mi  ssi  ssauga 
Los  Angeles 
Toronto 


Notes : 

1.  Initial  software  development  only  is  listed  here. 

2.  These  companies  are  no  longer  in  the  APC  business. 
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Software  Support  Contract  Cost: 


COTA: 


Kalamazoo  Metro: 


$  2,700  per  month  (includes  some  hardware  maintanence 
and  software  modifications) 

$  2031  per  month  (data  files  provided  on  disks  and  9 
track  tapes) 


Annual  range: 


$24,000-$32,400 


In-house  Software  Development 

Four  transit  agencies  have  fully  or  partially  developed  their  APC  software  in- 
house:  Portland,  Seattle,  and  Toronto  have  undertaken  full  development,  and 
Mississauga  is  in  the  process  of  developing  software  with  Systemware,  a  private 
consulting  firm  in  Ontario.  Based  on  the  experiences  of  these  properties,  in- 
house  development  requires  at  least  two  years  to  complete.  This  approach  has 
worked  best  when  the  services  of  computer  technicians  are  available  locally. 
These  services  may  be  housed  within  the  agency  or  they  may  be  obtained  on  a 
contract  basis  from  within  the  local  area.  Nearby  universities  and  technical 
schools  may  prove  to  be  a  valuable  resource  for  programmer  assistance  and 
software  development. 

In-house  Development  Cost: 

TRIMET:  1.5  person  years  to  date 

METRO:  2  person  years  to  date 

Software  Acquisition 

Final  options  are  to  request  proposals  for  software  development  contracts,  or  to 
obtain  the  software  from  another  property  and  modify  as  necessary  to  match  the 
data  needs  and  hardware  facilities  of  the  agency.  Modifying  programs  comprises 
the  major  portion  of  acquired  software  expense.  For  this  reason,  agencies  can 
minimize  software  costs  by  purchasing  software  which  is  designed  to  be  used  with 
the  same  type  of  stationary  computer  they  have  available  for  APC  use. 

In  existing  applications,  software  costs  ranged  from  $3000  for  very  rudimentary 
software  with  limited  capabilities  to  $250,000  for  very  sophisticated  software. 
One  software  developer  estimated  the  price  of  software  to  create  data  files 
within  the  range  of  $15,000-$60000,  with  the  precise  price  depending  on  the 
extent  of  modifications  required.  These  estimates  do  not  include  the  cost  of 
the  SPSS  or  SAS  software  to  generate  reports.  Also,  command  files  must  be 
written  to  create  a  systems  file  from  these  two  files. 

Software  Acquisition  Cost: 

Data  Base  software:  $15,000-$  60,000 
Actual  Prices  Paid:        $  3,000-$250,000 


4.2.3  PERSONNEL 

Personnel  is  a  key  component  of  an  APC  system,  but  one  which  is  frequently 
underestimated  by  user  properties.  The  implementation,  coordination, 
monitoring,  and  management  of  an  APC  project  are  time-consuming  processes.  The 
complexity  of  APC  system  operation,  as  demonstrated  in  the  procedures  discussed 
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in  section  4.6  (APC  System  Implementation),  mandates  that  agencies  make  strong 
commitments  to  APC  projects.  The  assignment  of  a  specialist  to  the  project 
facilitates  integration  of  the  system  into  on-going  transit  operations.  This 
person  is  a  critical  link  between  the  request  for  information  and  the  production 
of  reports. 

The  tasks  performed  by  the  specialist  include:  managing  the  vendor;  monitoring 
the  equipment;  diagnosing  hardware  problems;  assuring  the  assignment  of  APC 
buses  to  specified  routes;  enterring  and  processing  data;  updating  schedule 
files;  and  running  the  programs  to  produce  reports.  At  some  agencies,  the  APC 
specialist  is  responsible  for  data  transfer  as  well.  Based  on  their  experiences, 
user  properties  advise  that  at  least  one  full-time  person  is  needed  to 
coordinate  an  APC  project.  At  agencies  which  lack  the  resources  to  make  this 
commitment,  long  delays  in  achieving  operational  status  of  the  APC  system  have 
resulted. 

A  second  personnel  requirement  of  APC  systems  is  the  assignment  of  one  person 
from  .2  to  .5  FTE  (full-time  equivalent)  to  APC  maintenance.  It  is  important 
that  at  least  one  person  in  the  maintenance  department  be  knowledgable  about  APC 
hardware  to  assure  long-term  maintenance  of  the  equipment.  This  is  especially 
important  for  agencies  located  a  great  distance  from  their  suppliers.  It  has 
also  been  advised  that  the  maintenance  department  become  involved  from  the 
beginning  of  the  project  when  the  hardware  is  first  installed.  In  this  way,  the 
agency  is  able  to  replace  worn  or  defective  parts  over  time.  The  agency  should 
specify  training  requirements  in  an  RFP  to  facilitate  these  processes. 


4.3  Accuracy  and  Reliability  Issues 


In  general,  properly  installed  and  well  maintained  APC  systems  are  capable  of 
accurately  and  reliably  providing  ridership,  schedule  adherence,  and  system 
performance  data.  Almost  all  of  the  properties  interviewed  expressed 
satisfaction  with  the  accuracy  of  their  APC  data,  but  they  were  less  satisfied 
with  the  reliability  of  the  hardware. 

Appropriate  data  accuracy  levels  depend  on  the  intended  uses  of  the  data.  The 
relative  satisfaction  of  the  agencies  with  the  accuracy  of  their  data  is  thus 
determined  by  the  extent  to  which  agencies  believe  APC  error  will  influence 
decisions  based  on  the  data.  APC  data  accuracy  has  been  tested  by  a  number  of 
agenices,  consultants,  and  suppliers  (see,  for  example,  UMTA  1982;  National 
Research  Council  1984;  City  of  Calgary  1983). 

APC  data  accuracy  issues  are  summarized  as  follows: 

1.  Under  conditions  where  manual  checkers  have  been  aware  that  their 
performance  was  being  evaluated,  tests  comparing  the  accuracy  of  manual 
counts  to  APC  counts  have  concluded  that  there  is  no  significant  difference 
in  the  relative  accuracy.  In  tests  conducted  by  individual  properties 
comparing  APC  data  to  data  obtained  by  either  management  staff  or  revenue 
information,  the  accuracy  of  APC  data  was  demonstrated  at  between  98-100% 
within  ±1. 

2.  Studies  have  shown  treadle  mats  to  be  slightly  more  accurate  than  infrared 
beams  in  counting  passengers.  Although  more  factors  influence  the  accuracy 
of  beams  than  of  mats,  this  accuracy  difference  is  significant  only  when 
beams  cannot  meet  the  specified  accuracy  levels  of  individual  properties. 
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3.  Major  factors  affecting  the  accuracy  of  both  types  of  counting  sensors  are: 
children  carried  on-board  and  walking  off  the  bus;  people  passing  on 
stairwells;  and  people  standing  in  stairwells.  Two  types  of  error  are 
introduced  by  these  conditions:  error  in  total  counts  and  error  in 
passenger  load  counts.  Passenger  load  is  the  number  of  people  on-board  the 
bus  at  any  given  time. 

4.  Since  APCs  tend  to  count  boardings  more  accurately  than  deboardings,  some 
properties  have  used  total  boardings,  boardings  per  hour,  and  boardings  per 
mile  as  indicators  of  productivity  and  system  performance. 

5.  "On-off  di screpency" ,  or  the  difference  between  boarding  and  deboarding 
counts,  must  be  take  into  account  when  APCs  will  be  used  to  obtain  maximum 
load  counts,  maximum  load  points,  and  load  as  a  percent  of  capacity.  There 
are  at  least  three  measures  which  can  minimize  the  impacts  of  the 
conditions  causing  on-off  di screpencies: 

(a)  door  switches  can  be  used  to  control  or  monitor  counts  taken  when  bus 
doors  are  closed; 

(b)  buses  with  narrow  stairwells  allowing  passage  of  only  one  passenger 
stream  at  a  time  can  be  APC  equipped;  and 

(c)  software  routines  can  identify  trends  in  the  occurrence  of  on-off 
discrepency  and  assign  weights  to  boardings  or  deboardings  at 
specific  points  to  compensate  for  observed  differences. 

6.  At  most  properties,  differences  between  ons  and  offs  that  amount  to  more 
than  10-15%  of  the  counts  for  runs  are  not  tolerated  and  these  data  are 
discarded.  When  this  procedure  is  used,  it  should  be  applied  to  the  lowest 
feasible  level  of  disaggregation  to  minimize  the  amount  of  data  lost. 

7.  The  accuracy  of  location  data  presented  the  greatest  difficulty  for  some 
user  properties.  Signposts  can  significantly  increase  the  accuracy  of 
location  data  especially  when  the  signposts  are  used  at  major  time  points 
and  end  points  of  trips.  Systems  using  signpost  techniques  which  reset  the 
APC  odometer  to  zero  at  specific  intervals  have  accurate  location 
referencing.  Other  systems  which  record  the  signpost  field  entry  and  exit 
codes  and  use  software  to  interpolate  between  the  two  points  to  derive 
location  have  also  been  successful,  but  more  sophisticated  software  is 
required  for  this  method. 

8.  APCs  are  capable  of  disaggregating  to  the  bus  stop  level;  but  this  level  of 
disaggregation  is  often  not  desired  because  the  volumes  of  data  are 
overwhelming  and  because  the  costs  of  obtaining  stop-level  data  outweigh 
the  benefits. 

Reliability  issues  with  APC  hardware  are  summarized  as  follows: 

1.  Most  properties  report  that  unit  reliability  is  a  problem;  but,  the  general 
concensus  is  that  proper  system  maintenance,  monitoring  and  operational 
procedures  significantly  improve  the  reliability  of  the  hardware.  APC 
transit  personnel  are  quoted  as  saying:  "these  systems  require  alot  of 
babysitting";  "the  data  are  as  good  as  people  make  them";  "these  systems  do 
not  run  by  themselves,  especially  in  the  beginning";  and  "a  large 
commitment  of  time  is  required  to  get  these  systems  up  and  running  and 
functioning  properly." 
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2.  Major  reliability  issues  of  mats  are:  damage  caused  by  wheelchairs;  damage 
caused  during  repair  of  wheelchair  lifts;  and  water  infiltration.  To 
minimize  these  affects:  mats  can  be  used  on  buses  with  no  wheelchair 
lifts;  mats  can  be  placed  on  the  first  step  and  floor  level;  maintenance 
personnel  can  be  trained  in  the  function  of  APC  hardware  and  wiring;  and 
stairwell  heaters  can  be  used  to  decrease  the  impacts  of  water  and  melting 
snow  and  ice. 

3.  Major  reliability  issues  of  the  beams  are:  improper  lighthead  alignment 
preventing  the  completion  of  the  light  stream;  passenger  hands  on 
stanchions  blocking  the  streams;  dust  accumulation  on  the  lightheads  or 
reflectors  preventing  light  transmission  or  reception;  lightheads  being 
knocked  out  of  alignment  by  passengers;  and  scratched  reflector  surfaces. 
These  issues  can  be  resolved  by  proper  bus  and  APC  maintenance  and 
monitoring  procedures  and  by  optimal  positioning  and  installation  of  the 
lighthead  pairs  and  reflectors. 


4.4  APC  Benefits 

APCs  are  viewed  by  user  properties  as  a  powerful  tool  for  transit  planning, 
operations,  and  management.  Although  properties  are  quick  to  caution  about  the 
need  to  approach  APC  implementation  slowly  and  to  realistically  assess  the 
required  commitment  of  resources,  almost  all  of  the  properties  stated  without 
hesitation  that  they  would  repeat  their  APC  experiences. 

The  expansion  of  APC  applications  to  six  additional  North  American  properties 
within  the  last  three  years  attests  to  the  general  viability  of  the  technique. 
The  value  of  APCs  for  small  properties  is  evidenced  in  Michigan's  plans  to  apply 
APCs  to  three  additional  small  transit  districts  in  the  state.  The  Michigan 
Department  of  Transportation's  decision  to  implement  APCs  at  these  properties 
was  based  on  the  perceived  cost-effectiveness  of  the  APC  project  at  Kalamazoo, 
Michigan,  a  property  comparable  in  size  and  service  area  population  to  Lane 
Transit  Di strict. 

APC  benefits  are  realized  both  in  the  short  and  long  run.  In  the  short  run,  APCs 
reduce  the  need  for  manual  data  collection  activities;  in  the  long  run,  when  an 
APC  system  is  fully  operational,  this  need  is  completely  eliminated.  In 
addition,  unlike  manual  data  collection  techniques  which  require  time  and  money 
commitments  for  training,  supervising,  and  periodic  hiring  of  part-time 
workers,  APCs  are  autonomous  and  continuously  available.  Although  some 
operational  costs  are  associated  with  the  use  of  APCs,  studies  comparing  manual 
to  automatic  data  collection  methods  have  found  that  the  on-going  costs  of 
manual  methods  exceed  the  on-going  costs  of  automated  techniques  for  comparable 
data  collection  efforts. 

Other  APC  benefits  are  more  difficult  to  quantify,  but  nevertheless  contribute 
to  the  overall  cost-effectiveness  of  APCs.  One  such  benefit  is  the  significant 
reduction  in  turn-around  time  between  observation  and  reporting  of  events.  Very 
long  turn-around  times  are  usually  associated  with  manual  data  collection 
techniques.  With  APCs,  reports  can  be  produced  within  one  week  from  the  time 
observations  are  made. 

Because  automatic  counting  systems  efficiently  generate  accurate  data  on 
passenger  activity  by  location  and  time,  APCs  demonstrate  their  most  immediate 
effects  in  transit  planning.  For  planning,  APCs  provide  access  to  a  much  larger 
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pool  of  information  to  assess  the  current  and  future  needs  of  the  transit 
population.  For  example,  APCs  provide  on-going  and  ready  access  to  data  on 
passenger  loads,  route  profiles,  and  load  as  a  percent  of  capacity.  With  the 
use  of  APC  technology,  this  information  can  be  available  on  a  daily,  weekly, 
monthly,  or  quarterly  basis.  Access  to  this  information  is  an  important  asset 
in  locating  bus  stops  and  bus  shelters  and  in  devising  route  restructuring 
strategies.  An  indirect  benefit  of  APCs  could  be  the  increased  public  support 
for  route  changes  based  on  more  complete  data  obtained  from  APCs. 

For  scheduling  activities,  the  time  performance  reports  generated  by  APCs 
provide  valuable  indicators  on  how  well  time  schedules  match  on-the-road 
conditions.  Based  on  APC  data,  schedules  can  be  changed  to  more  accurately 
reflect  actual  arrival  and  departure  times.  Service  improvements  resulting  from 
APC  data  also  have  the  indirect  benefit  of  improving  public  relations  and 
increasing  public  support  for  the  transit  district. 

APC  benefits  are  particularly  evident  in  the  use  of  APC  information  by  transit 
management.  The  APC  benefits  most  frequently  cited  by  user  properties  are 
increased  productivity  and  revenue  saved  by  taking  buses  off  non-productive 
routes.  With  APCs,  system  performance  indicators  such  as  passenger  miles, 
passengers  per  hour,  boardings  per  hour,  and  boardings  per  mile,  are  reported 
both  routinely  and  on  demand  for  specified  time  periods.  The  productivity 
reports  produced  from  these  data  are  valuable  indicators  of  the  system  and  route 
performance.  The  cost  savings  realized  from  access  to  this  information  can  be 
significant.  For  example,  one  property  estimates  that  for  every  bus  taken  out 
of  the  system,  the  property  saves  about  $178,000  per  year  in  operating  expenses. 
This  estimate  does  not  include  capital  costs  of  the  bus. 

In  addition,  many  properties  use  APCs  to  collect  and  analyze  data  to  fulfill 
UMTA  Section  15  reporting  requirements.  Due  to  the  high  level  of  accuracy 
required  by  Section  15  (95%  confidence  at  ±10%  tolerance)  for  systemwide  data, 
the  costs  of  manually  collecting  these  data  are  high.  A  fully  operational  APC 
system  can  perform  this  task  as  part  of  a  normal  daily  routine  at  minimal 
additional  cost  to  the  property. 

Potential  benefits  of  automated  data  collection  techniques  are  their 
applications  in  marketing  and  policy  setting  activities.  The  application  of  APCs 
to  marketing  has  been  limited  because  the  more  immediate  applications  discussed 
above  have  received  priority.  One  property  is  now  developing  a  marketing 
strategy  based  on  APC  data  by  integrating  it  with  survey  and  census  data. 
Similarly,  the  use  of  APC  data  in  setting  long  term  transit  goals  has  been 
limited.  Again,  this  is  due  primarily  to  the  fact  that  it  is  relatively  new 
technology.  It  is  conceivable  that  APCs  will  play  a  valuable  role  in  these 
endeavors  in  future  applications. 

4.4.1  REPORTS 

APC  data  on  ridership,  time,  and  location  are  used  to  produce  three  types  of 
reports: 

(1)  Passenger      loading      profiles      used     to      identify     overloading  and 
underuti 1 ization ; 

(2)  Time  performance  reports  used  for  route  scheduling;  and 
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(3)    System  performance  indicators  used  for  transit  management. 

These  reports  can  be  produced  for  different  time  periods  ranging  from  15  minute 
periods  to  quarterly  or  seasonal  reports.  They  are  presented  in  both  graphic 
and  tabular  format.  APC  data  can  be  incorporated  with  survey  data  for  trend 
analyses,  but  additional  programs  are  needed  for  this  purpose.  The  sample 
reports  on  the  following  pages  serve  as  examples. 
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4.5  APC  Costs 


There  are  two  cost  factors  to  consider  in  assessing  the  cost-effectiveness  of 
APCs:  total  cost  and  relative  cost.  Table  4.4  displays  the  total  cost  of  an  APC 
system  consisting  of  on-board  equipment  for  20  buses,  a  minicomputer,  50 
signposts,  including  all  installation,  wiring,  miscellaneous  costs  and  software 
acquisition  costs.  These  estimates  are  based,  whenever  possible,  on  direct 
quotes  from  suppliers.  Otherwise,  a  range  of  costs  is  presented  which  is  based 
on  the  prices  of  the  most  recently  purchased  systems.  The  large  disparity 
between  the  low  and  high  estimates  is  due  to  the  costs  of  the  various  hardware 
options  and  to  the  wide  range  in  software  costs.  The  individual  case  studies 
contain  separate  sections  on  cost,  and  the  reader  is  referred  to  Chapter  Three 
for  more  information  on  the  individual  costs  of  system  components. 

In  Table  4.4,  direct  costs  include  capital  costs  of  hardware  and  software  and 
annual  costs  of  data  processing  and  personnel.  The  total  capital  cost  of  an  APC 
system  (including  all  wiring  and  installation  costs)  with  20  APC  buses,  50 
signposts,  mini-computer,  and  software  to  create  data  files  ranges  from  $165,300 
to  $284,300.  Total  annual  costs  include  personnel,  spare  parts,  and  data 
processing  costs.  Although  annual  costs  tend  to  vary  from  property  to  property, 
the  personnel  requirements  in  Table  4.4  are  the  minimum  needed  for  an  effective 
APC  system. 

Note  from  Table  4.4,  that  the  capital  cost  of  an  APC  system  is  highly  sensitive 
to  software  costs,  especially  for  small  properties.  For  small  transit  agencies, 
software  costs  can  exceed  all  other  capital  costs  of  the  system  combined.  The 
most  extensive  improvements  in  APC  technology  have  been  in  software  rather  than 
hardware  modifications.  With  few  exceptions,  the  hardware  used  in  current 
applications  is  very  similar  to  the  technology  employed  in  the  earliest  APC 
applications.    In  contrast,  major  advances  have  been  made  in  software  design. 

The  second  cost  factor  to  consider  is  the  cost  of  APCs  relative  to  current  data 
collection  methods.  This  comparison  should  be  based  on  comparable  data 
collection  efforts.  APCs  generally  provide  more  and  better  quality  data  than 
has  been  gathered  using  past  manual  techniques.  The  level  of  effort  is 
determined  by  the  data  needs  of  the  individual  property.  Aside  from  data  needs, 
other  factors  enter  into  the  analysis  including:  peak  fleet  size;  the  number 
sign-ups  per  year;  the  type  of  method  currently  used;  the  number  of  people 
employed  to  collect  data;  and  the  number  and  type  of  APC  system  components. 
These  factors  are  displayed  for  current  APC  user  properties  in  Table  4.5. 
Although  no  analysis  of  these  variables  has  been  performed  for  the  purposes  of 
this  study,  this  table  illustrates  one  means  of  making  this  comparison. 

Figure  4-1  displays  the  relative  costs  of  APCs.  This  comparison  was  made  by 
Deibel  and  Zumwalt  in  1984.  According  to  the  analysis  performed  by  these 
authors,  for  large  transit  agencies,  which  utilize  a  large  checker  staff,  the 
annual  cost  of  APCs  approximates  the  annual  cost  of  checker  salaries  alone. 
When  based  on  comparable  data  collection  efforts,  their  analysis  reveals  that 
APCs  are  significantly  more  cost-effective  than  manual  methods  for  large 
properties . 

Since  many  small  transit  agencies  rely  on  smaller  sample  sizes  and  often  do  not 
retain  permanent  checker  staffs,  cost-effectiveness  of  APCs  for  small  agencies 
is  more  a  function  of  the  agencies'  perceived  data  needs.  These  agencies  should 
compare  the  benefits  of  APC  data  (including  both  direct  and  indirect  benefits) 
to  the  costs. 
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Table  A. 4:    Estimated  Total  Costs  Of  APC  Acquisition  And  Implementation 


Fixed  Costs 


Low  Estimate 


High  Estimate 


On-board  equipment  (20  buses) 
(counter  and  door 
sensors,  DCU,  signpost 
antennae  including  installation 
and  2  year  warranty) 

Signposts  (50) 

(including  installation  and 

2  year  warranty) 

Data  Retrieval  Device 

Minicomputer 


Software  Acquisition 


1 


$  76,300 

$  64,000 
$  4,000 
$  6,000 
$  15,000 


$136,300 

$  64,000 
$  14,000 
$  10,000 
$  60,000 


Total  Fixed  Costs: 


$165,300 


$284,300 


Annual  Costs 


APC  Technician  1  FTE 

APC  Maintenance^  .2  FTE 

Data  Processing  NA 

Training,  manuals,  spare  parts  NA 


1.5  FTE 
.5  FTE 
NA 
NA 


Notes : 

1.  Includes  only  the  cost  of  programs  to  create  data  files. 

2.  Assumes  project  supervision  will  be  performed  by  existing  staff. 

3.  Maintenance  will  increase  as  the  system  ages. 
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Table  A. 5:    Comparison  Of  Manual  To  Automatic  Data  Collection  Methods 


Property  Characteristics         Manual  Methods  APC  Methods 


Peak     tsign-ups  tAPC 

Fleet      Per  Year  Number    Type  Buses  isignposts 


APC  SYSTEMS 


Seattle 

915 

3 

8 

Ride  checker 

116 

226 

Ottawa 

710 

4 

8 

Ride  checker 

66 

32 

Kalamazoo 

31 

NA^ 

NA 

Driver  counts 

20 

35 

1 ondon 

152 

NA 

NA 

Driver  counts 

18 

0 

Windsor 

78 

4 

NA 

Driver  counts 

27 

43 

Calgary 

435 

NA 

3 

Checker 

5 

0 

Portland 

424 

5 

5 

Ride  checker 

43 

0 

Columbus 

294 

3 

4 

Ride  checker 

20 

50 

Chicago 

950 

5 

28 

Checker 

6 

450' 

Kitchener 

70 

NA 

20 

Checker 

20 

0 

Mi  ssi  ssauga 

135 

NA 

NA 

NA 

30 

0 

AVM-APC  SYSTEMS 

Toronto 

1621 

NA 

NA 

NA 

100 

45 

Los  Angeles 

2100 

NA 

34 

Checker 

200 

900 

2 


Notes : 


1.  NA:  Information  not  available  or  not  applicable 

2.  Chicago  uses  signposts  for  emergency  response  as  well  as  APCs. 
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Figure  4-1:    Comparison  Of  Manual  And  Automated 
Data  Collection  Costs 


7U()(I()0 


r~l   l^lior  (Aiat   (Inclii.lliig  frlnto)      mi     Toul  Annual  Cost  of 
Assioclulcil  wiLli  fUiiiial  Hiiiiuol  liuLa  G>lluctluii 

Clieckur::! 

rni     TiiCul  Aiiiiii:il  C«sl  of  Oii-UnjrJ 

AuCuin.illc  Diilu  Cii  1 1  cc  C  Ion  Svitcra 

Source:  "Modular  Approach  To  On-Board  Data  Collection 

Systems".  Lawrence  E.  Deibel  and  Barbara  Zumwalt, 

Mitre  Corporation,  McLean,  Virginia.  For  the 

National  Research  and  Development  Program.  Report  9.  1984 
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4.6  APC  System  Implementation 


The  first  question  agencies  must  address  is  whether  or  not  to  implement  an  APC 
system.  The  response  should  be  based  primarily  on  an  evaluation  of  the  agency's 
data  needs.  This  evaluation  should  identify  intended  uses  of  the  data.  If  an 
agency  decides  to  implement  an  APC  system,  it  can  base  its  APC  functional 
requirements  on  these  specified  data  needs.  Figure  4-2  suggests  uniform 
functional  requirements  for  APC  systems.  These  requirements  were  proposed  by 
the  Canadian  Urban  Transit  Association  (APC  Functional  Requirments  Definition. 
1983)  in  an  effort  to  encourage  uniformity  in  the  design  of  APC  systems. 

In  deciding  the  appropriate  number  of  buses  to  APC-equip,  agencies  need  to 
consider  several  factors  including:  intended  uses  of  the  data;  fleet  size; 
route  structure;  and  average  expected  down  time  of  the  system.  Generally, 
routes  need  to  be  sampled  about  five  times  during  a  sign-up  to  obtain  an 
adequate  three  day  sample;  but  experience  with  the  system  over  time  will  provide 
additional  information  on  both  data  needs  and  appropriate  sample  size. 
Incremental  hardware  acquisition  is  advised  to  allow  identification  of 
unanticipated  data  needs  and  a  realistic  assessment  of  adequate  sample  size. 
Another  advantage  of  incremental  hardware  acquisiton  is  that  it  minimizes  up- 
front capital  costs  of  the  system.  A  general  rule  adopted  by  many  agencies  is  to 
equip  12%  of  the  fleet.  The  rough  estimate  derived  from  this  rule  can  be  used  to 
assess  the  long-term  costs  of  the  system. 

In  making  individual  estimates  of  sample  size,  agencies  need  to  take  the  average 
down  time  of  the  system  into  account.  Although  this  varies  from  property  to 
property,  many  agencies  report  that  about  80%  of  the  vehicles  are  available  on 
any  given  day.  Because  the  age  and  condition  of  APC  buses  affect  the  down  time  of 
the  system,  newer  buses  in  good  condition  should  be  APC  equipped. 
Operational  procedures  have  been  one  of  the  biggest  impediments  to  successful 
APC  implementation.  For  some  properties,  there  have  been  problems  assigning 
buses  to  routes  and/or  verifying  APC  bus  assignments.  This  type  of  problem  is 
particularly  evident  in  cases  where  APCs  interfere  with  other  transit  functions. 
For  example,  bus  driver  or  security  guard  involvement  in  APCs  has  not  proven 
very  reliable  since  these  employees  have  responsibilities  which  take  priority 
over  APC  data  transfer  or  monitoring.  Also,  at  agencies  where  APCs  have  been 
viewed  by  drivers  as  a  threat,  sabotage  of  the  hardware  and  a  lack  of  driver 
cooperation  have  resulted. 

APC  system  implementation  and  operation  are  complex  processes,  requiring  a  large 
commitment  of  time.  The  flow  chart  in  Figure  4-3  (City  of  Calagary  Report.  1983) 
provides  a  clear  indication  of  the  degree  of  human  involvement  in  APC  systems 
and  the  complexity  of  the  data  collection  process.  This  flow  chart  illustrates 
the  need  for  both  interdepartmental  cooperation  and  a  project  coordinator  (APC 
specialist  discussed  in  section  4,2.3).  At  Calgary,  at  least  five  departments 
are  involved  in  the  process:  schedules,  planning,  maintenance,  dispatching,  and 
electric  systems.  Although  this  process  and  the  participating  departments  vary 
from  property  to  property,  the  involvement  of  dispatching,  planning  (including 
scheduling),  and  maintenance  is  necessary  for  all  systems.  Interdepartmental 
cooperation  is  essential  for  successful  APC  implementation,  and  the  system  works 
best  when  all  departments  (planning,  maintenance,  dispatching,  etc.)  have  a 
stake  in  the  outcome  of  the  project.  Cooperation  may  be  elicited,  especially 
when  resistance  is  anticipated,  by  the  strong  support  of  transit  management  and 
by  the  use  of  incentives. 
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Figure  4-3  also  illustrates  the  complexity  of  APC  systems,  emphasizing  the  need 
for  a  project  coordinator.  For  example,  there  are  several  steps  involved  just 
in  the  deployment  of  APC  coaches  to  their  assigned  routes.  Seattle  uses  a 
calender  system  for  this  purpose.  This  system  is  illustrated  in  Figure  4-4.  The 
calender  is  prepared  by  planning  on  a  weekly  basis  and  sent  to  dispatching  where 
the  actual  assignments  are  made.  To  create  this  calender,  it  is  necessary  to 
determine  which  routes  to  sample  for  a  given  time  period,  day,  and  season.  The 
system  must  also  take  into  account  the  number  of  times  routes  need  to  be  sampled 
to  estimate  between-day,  within-day,  and  seasonal  variation.  The  data  must  be 
validated  and  some  routes  may  need  to  be  resampled.  These  are  just  a  few  of  the 
steps  required  to  obtain  adequate  samples.  Yet,  this  element  represents  only  a 
part  of  the  overall  data  collection  process. 


4.7  Summary 


Many  APC  systems  have  achieved  the  objectives  originally  established  by  the  user 
properties  and  the  majority  of  the  transit  agencies  interviewed  stated  that  they 
would  repeat  their  APC  experience.  APCs  have  been  used  by  small  as  well  as  large 
properties  and  type  of  route  structure  is  not  a  factor  influencing  the 
application  of  APC  systems.  All  of  the  properties  using  APCs  are  peak-oriented 
systems . 

The  status  of  existing  APC  systems  is  displayed  in  Table  4.6.  All  properties  in 
Table  4.6  are  currently  undertaking  either  initial  APC  installation  or  system 
modifications.  These  modifications  are  fully  explained  in  the  case  studies  In 
Chapter  Three  and  the  reader  is  advised  to  refer  to  this  chapter  for  a  complete 
description  of  these  systems.  This  information  is  summarized  in  Table  4.6  to 
provide  an  easy  reference  for  the  reader  and  to  illustrate  the  tendency  of  user 
properties  to  expand  and  modify  their  APC  systems  over  time. 

In  sum,  there  are  a  variety  of  hardware  and  software  options  open  to  transit 
agencies  contemplating  or  planning  a  conversion  to  automated  data  collection 
techniques.  Choice  of  system  components  is  a  function  of  the  agency's  data  needs 
and  resources.  Because  these  conditions  vary  from  property  to  property,  agencies 
should  conduct  their  own  analyses  based  on  their  perceived  data  needs,  available 
resources,  present  methods,  and  property  characteri sitics.  The  benefits,  costs 
and  operational  considerations  outlined  in  this  chapter  can  serve  as  a  guide  for 
these  analyses. 

Successful  implementation  of  an  APC  system  requires  a  high  level  of 
interdepartmental  cooperation,  carefully  designed  procedures,  and  a  large 
commitment  of  time  on  the  part  of  transit  agency  staff  directly  involved  with 
the  project.  The  level  of  commitment  made  to  the  project  is  a  key  factor 
influencing  the  successful  and  timely  operation  of  the  system.  If  agencies  are 
unable  to  commit  sufficient  resources,  including  personnel,  to  the  project,  more 
time  will  be  needed  for  the  system  to  become  fully  operational. 
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Merge    Raw    APC  Data 
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Produce    APC    Master  File 
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Figure  4-2:  AUTOMATIC  PASSENGER  COUNTING  SYSTEM  FUNCTIONAL  BREAKDOWN 
Source:  "APC  Uniform  Functional  Requirements  Definition" 
Canadian  Urban  Transit  Association.  1983 
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Table  4.6  :    Modifications  Of  Existing  APC  Systems 


Implementation 
Year 


Modification 


APC  Systems 
Seattle 


Ottawa 


Kalamazoo 

London 
Windsor 

Calgary 
Portland 


Kitchener 


1978       Equip  60  more  buses 

Software  Development  for 
stop-ref erenci  ng 


1978 


1980 

1981 
1981 

1982 
1982 


Columbus  1982 
Chicago  1983 


1985 


Upgrade  hardware 
Install  32  signposts 
Manual  to  radio-link 
transfer  conversion 
Software  development 

Purchase  IBM  PC  AT 
Purchase  software  to 
process  APC  data  in-house 

Improve  treadle  sensor  mats 
Expand  APC  system 

Increase  disk  capacity 

Obtain  programmer  documentation 

Remedy  signpost  problem 

Equip  20  more  buses 
Equip  total  fleet 

Switch  door  sensor  design 
Repair  sensors  under  warranty 
Equip  10  more  buses 
Software  enhancement 


status 


Installed;  Expect 
Completion  Sum  '85 

Compl eted 

In  progress 

Testing  3  prototypes 

Hardware  installed 
Expect  completion  3/86 


In  progress 

In  progress 
Long-range  goal 

PI anni  ng 

RFP 

RFP 

Market  study 
Long-range  goal 

Planni  ng 
In  progress 
Planning 
In  progress 


Install  20  APCs  and  50  signposts    In  progress 


Begin  first  phase  of  APC 
acquistion  and  implementation 
Equip  270  buses 

APC  hardware  and  software 
installation  and  implementation 


Mississauga       1985       APC  system  implementation 


Funding  approved 
Long-range  goal 


In  progress 

In  progress 


AVH-APC  Systems 

Toronto  1978 

Los  Angeles  1980 


Equip  150  buses 

Evaluate  present  system 
Upgrade  hardware 
Enhance  software 
Equip  100%  fleet  with 
radio  transmitters 


Writing  specifications 

Hired  specialist 
Eval uati  ng 
Eval uati  ng 

Planni  ng 
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Chapter  Five 
Conclusions  And  Recommendations 


Use  of  APC  techniques  in  North  America  has  been  limited,  with  less  than  twenty 
transit  agencies  having  operational  APC  systems.  The  duration  of  APC  use  in 
North  America  has  also  been  limited,  beginning  in  1978  in  Seattle  and  Ottawa. 
Furthermore,  all  of  the  researched  systems  installed  since  1978  are  now  being 
expanded  or  modified  to  increase  cababilities  or  improve  reliability. 

APC  hardware  and  software  are  capable  of  accurately  and  reliably  collecting  and 
analyzing  data  on  transit  passenger  counts,  running  times,  and  location.  Hard 
copy  reports  on  overloading  and  underuti 1 i zati on  conditions,  schedule 
adherence,  and  system  performance  indicators  can  be  produced  by  APC  systems. 
Data  turnaround  time  can  be  less  than  one  week. 

For  these  reasons,  many  transit  agencies  would  do  well  to  implement  APC  systems. 
This  general  conclusion  does  not  apply  to  all  agencies,  however,  since  the 
applicability  of  APCs  to  individual  transit  agencies  depends  on  a  variety  of 
factors.  Of  these,  intended  use  of  the  data  is  the  most  important.  Other 
critical  issues  are:  APC  system  components,  data  accuracy  and  reliability, 
cost-effectiveness,  and  implementation.  The  following  conclusions  address 
major  concerns  related  to  each  of  these  factors.  These  conclusions  are  followed 
by  recommendations  on  APC  implementation  at  Lane  Transit  District. 

Conclusions 

1.  The  decision  to  convert  to  automated  data  collection  techniques  should  be 
based  on  a  careful  evaluation  of  an  agency's  data  needs.  The  intended  uses 
of  the  data  should  be  the  overriding  consideration  in  both  the  decision  to 
implement  an  APC  system  and  the  specifications  for  an  APC  system. 

2.  Appropriate  sample  sizes  and  accuracy  levels  are  determined  by  the  intended 
uses  of  the  data.  For  example,  properties  using  APC  systems  in  conjunction 
with  real-time  monitoring  systems  (AVM)  have  high  accuracy  standards  for 
location  data  since  the  data  are  primarily  used  for  operations  control  and 
emergency  response. 

3.  The  majority  of  properties  surveyed  expressed  satisfaction  with  the 
accuracy  of  their  APC  data.  The  accuracy  of  location  data  presented  the 
greatest  difficulty  for  some  user  properties.  Signposts  can  significantly 
increase  the  accuracy  of  location  data  especially  when  the  signposts  are 
used  at  major  time  points  and  end  points  of  trips. 

4.  Most  properties  report  that  unit  reliability  is  a  problem;  but,  the  general 
concensus  is  that  proper  system  maintenance,  monitoring  and  operational 
procedures  significantly  improve  the  reliability  of  the  hardware. 

5.  The  most  extensive  improvements  in  APC  technology  have  been  in  software 
rather  than  hardware  modifications.  With  few  exceptions,  the  hardware  used 
in  current  applications  is  very  similar  to  the  technology  employed  in  the 
earliest  APC  applications.  In  contrast,  major  advances  have  been  made  in 
software  design . 
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6.  Fortran  programs  are  often  used  to  create  data  files;  and  SPSS  packaged 
software  is  frequently  used  to  access  data  files  and  generate  reports. 
Software  modifications  needed  to  convert  the  Fortran  programs  for  use  on 
different  host  computers  comprise  a  major  portion  of  the  software  costs. 

7.  Programmer  documentation  is  needed  to  modify  and  enhance  the  software  over 
time.   Well  written  users'  manuals  facilitate  use  of  the  system. 

8.  Personnel  is  a  key  but  often  underestimated  component  of  an  APC  system. 
Minimal  personnel  requirements  reported  by  APC  properties  include  at  least 
one  full  time  person  to  manage  and  coordinate  the  APC  project  and  at  least 
one  person  half^-time  to  maintain  the  hardware. 

Transit  personnel  are  quoted  as  saying:  "these  systems  require  alot  of 
babysitting";  "the  data  are  as  good  as  people  make  them";  "these  systems  do 
not  run  by  themselves,  especially  in  the  beginning";  and  "a  large 
commitment  of  time  is  required  to  get  these  systems  up  and  running  and 
functioning  properly." 

9.  The  capital  cost  of  an  APC  system  is  highly  sensitive  to  software  costs, 
especially  for  small  properties  (100  peak  buses  or  less).  For  small  transit 
agencies,  software  costs  can  exceed  all  other  capital  costs  of  the  system 
combi  ned. 

10.  The  cost-effectiveness  of  APCs  is  determined  by  comparing  the  benefits  of 
the  system  to  the  costs  and  by  comparing  the  costs  of  current  data 
collection  methods  to  APC  costs.  The  comparison  of  APCs  to  current  methods 
must  be  measured  by  comparable  data  collection  efforts. 

11.  Some  of  the  costs  and  benefits  of  APCs  are  difficult  to  quantify;  and 
indirect  benefits  as  well  as  direct  benefits  of  the  system  should  be 
identified. 

12.  Depending  on  the  extent  and  expense  of  current  data  collection  efforts, 
APCs  can  be  significantly  more  cost-effective  than  manual  methods.  For 
large  agencies  with  permanent  checker  staffs,  APCs  approximate  the  costs  of 
checker  salaries  alone.  For  small  agencies  (less  than  100  peak  buses),  the 
cost-effectiveness  of  APCs  is  less  precisely  defined.  Individual  agencies 
need  to  determine  whether  the  benefits  (including  indirect  benefits)  of 
APCs  justify  the  costs. 

13.  The  functional  requirements  of  an  APC  system  depend  on  the  data  needs  and 
resources  of  individual  properties.  For  example,  APCs  are  capable  of 
disaggregating  to  the  bus  stop  level;  but  this  level  of  disaggregation  is 
often  not  desired  because  the  volumes  of  data  are  overwhelming  and  because 
the  costs  of  obtaining  stop-level  data  do  not  outweigh  the  benefits. 

14.  Operational  procedures  have  been  one  of  the  biggest  impediments  to 
successful  APC  implementation,  particularly  when  other  transit  functions 
have  taken  priority  over  APCs.  Thus,  interdepartmental  cooperation  is 
essential  for  successful  APC  implementation.  The  system  works  best  when 
all  departments  (Planning,  Maintenance,  Operations,  and  Management)  have  a 
stake  in  the  outcome  of  the  project. 

15.  APC  systems  are  strongly  affected  by  technological  change.  When  hardware 
becomes  obsolete,  spare  parts  may  be  unattainable  or  difficult  to  find. 
The  costs  of  retrofits  necessitated  by  product  obsolesence  are  minimized  by 
incremental  hardware  acquisition. 
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16.  At  transit  agencies  where  drivers  have  suspected  that  APCs  were  monitoring 
their  performance,  sabotage  of  the  hardware  and  a  lack  of  driver 
cooperation  have  resulted. 

17.  Type  of  bus  is  not  generally  a  factor  1n  the  success  of  APC  systems. 
However,  equipping  buses  with  wide  doorways  (allowing  passengers  to  pass 
each  other  on  the  stairwells)  should  be  avoided;  Articulated  buses  are  more 
costly  to  APC  equip  than  standard  buses  due  to  the  need  for  sensors  at  the 
third  door. 

18.  The  availability  of  APC  buses  is  affected  by  non-APC  maintenance  and  repair 
as  well  as  APC  maintenance  and  repair.  The  age  and  condition  of  APC- 
equipped  buses  affect  the  down-time  of  the  system. 


Recommendations 


1.  Lane  Transit  should  conduct  a  thorough  evaluation  of  its  data  needs  prior 
to  making  a  final  decision  to  implement  an  APC  system.  This  evaluation 
should  involve  interviewing  representatives  of  appropriate  departments  at 
Lane  Transit  (such  as  planning,  operations,  management,  finance, 
marketing,  etc.)  to  identify  the  types  and  amount  of  information  needed  by 
each  department.  This  evaluation  should  be  followed  by  an  assessment  of 
present  data  collection  techniques  in  light  of  their  cost-effectiveness  in 
providing  current  and  newly  identified  data. 

2.  Assuming  that  data  needs  are  identified  in  #1  which  cannot  be  met 
effectively  by  Lane  Transit's  current  methods.  Lane  Transit  should  proceed 
with  phased  implementation  of  an  APC  system.  This  recommendation  is  based 
on  the  conclusion  that,  given  the  need  for  the  volumes  and  types  of  data 
APCs  are  capable  of  generating,  transit  agencies  can  benefit  significantly 
from  the  use  of  APC  systems. 

3.  Lane  Transit  should  develop  an  APC  implementation  plan  which  details  a 
phased  implementation  process  best  suited  to  the  agency's  personnel, 
operational,  and  policy  characteristics.  The  plan  should  include  the 
fol lowing: 

(a)  A  procedure  to  disseminate  information  on  APCs,  their  use,  and  the 
roles  of  the  separate  departments  in  the  implementation  scheme.  This 
may  be  in  the  form  of  an  APC  committee  whose  members  represent  all  of 
the  departments  within  the  agency.  Each  department  should  feel 
"ownership"  of  the  system  and  play  a  responsible  role  in  the 
implementation  process. 

(b)  Clear  guidelines  identifying  the  changed  procedures  in  traditional 
operations  brought  about  by  implementation  of  APCs.  In  cases  where  APCs 
interfere  with  routine  operations,  sufficient  time  for  adjustment 
should  be  allowed. 

(c)  A  scheme  to  enlist  the  cooperation  of  all  departments.  Where  resistence 
is  anticipated,  incentives  can  be  used  to  facilitate  cooperation. 
Special  efforts  should  be  made  to  assure  drivers  that  APCs  will  not  be 
used  to  monitor  their  performance. 
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(d)  The  assignment  of  at  least  one  full-time  person  to  the  project.  If 
agency  resources  prohibit  the  hiring  of  additional  staff  and  present 
staff  is  inadequate  to  meet  this  requirement,  the  agency  should 
anticipate  a  longer  time  frame  for  the  system  to  become  fully 
operational . 

(e)  Hardware  specifications  written  in  fine  detail.  The  specifications 
should  describe:  the  functional  and  physical  requirements  of  the 
hardware;  performance  standards;  warranty  requirement;  a  provision  for 
training  on  the  installation  and  maintenance  of  the  system  including 
user  and  repair  manuals;  and  a  request  for  total  price  quotes  including 
all  wiring,  cables,  brackets,  and,  if  appropriate,  instal lation  costs. 
If  possible,  the  hardware  should  be  installed  by  Lane  Transit 
maintenance  staff  in  order  to  increase  the  agency's  competency  in  long- 
term  system  maintenance. 

(f)  Phased  APC  implementation  proceeding  with  the  purchase  or  lease  of  one 
or  two  units  and  signposts  in  the  first  year.  From  these  units,  more 
information  will  be  provided  on  which  to  base  decisions  about  future 
purchases. 

4.  The  RFP  should  be  sent  to  suppliers  or  vendors  for  review  prior  to  the 
formal  process  of  requesting  proposals.  Suppliers  have  stated  a  preference 
for  editing  RFPs  in  order  to  provide  more  realistic  expectations  of  the 
hardware.  For  the  agency,  this  step  will  provide  additional  information  on 
the  available  systems. 

5.  With  regard  to  software  development.  Lane  Transit  should  simultaneously 
explore  three  options: 

(a)  Purchasing  software  designed  for  use  on  the  host  computer  Lane  Transit 
intends  to  use  for  APC  data  processing; 

(b)  Gaining  access  to  programs  already  developed  by  or  for  other  transit 
agencies.  If  available  programs  are  incompatible  with  Lane  Transit's 
host  computer,  modifications  can  be  made  either  in-house  or  locally; 
and 

(c)  Pursuing  in-house  software  development  or  contracting  out  software 
development  to  a  local  firm  or  the  University  of  Oregon. 

6.  Based  on  user  experience,  in-house  development  is  a  time-consuming 
process,  taking  more  than  2  person  years  to  complete.  This  cost,  once 
known,  should  be  compared  with  the  cost  of  software  acquisition.  These 
costs  pertain  only  to  the  Fortran  programs  needed  to  create  data  files  and 
the  command  programs  needed  for  SAS  or  SPSS  to  access  these  files  and 
generate  reports.  (Lane  Transit  already  has  access  to  SPSS  and  SAS 
packages. ) 

7.  Programmer  documentation  and  a  user's  manual  should  accompany  the  APC 
software. 

8.  Since  the  condition  and  age  of  the  buses  affect  the  down-time  of  the  APC 
system,  newer  buses  in  good  condition  should  be  APC-equipped. 
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9.  If  Lane  Transit  intends  to  APC-equip  different  types  of  buses  in  the  long- 
run,  the  initial  installation  in  the  first  implementation  phase  should 
include  each  type  of  bus  that  will  eventually  be  APC-equi pped .  If 
feasible,  buses  with  wide  stairwells  should  not  be  APC-equi pped ;  and,  if 
articulated  buses  will  be  APC-equipped,  the  additional  expense  of 
equipping  articulated  buses  should  be  accounted  for  in  cost  estimates  of 
the  system. 
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Appendix  6.1 


APC  Hardware  Suppliers  and  Software  Developers 


Automatic  Passenger  Counting  Systems,  Ltd. 

635  Newbold  Street 

London,  Ontario,  Canada    N6E  2T8 

TELEX  064-7557 

Gandalf  Data  Limited 

Gandalf  Plaza 
9  Slack  Road 

Nepean,  Ontario,  Canada    K2G  0B7 
613-225-0555 

Group  Five  Consulting  Limited 
1215  Rooney's  Lane 
Ottawa,  Canada    KIH  7Y6 
613-521-4413 

London  Mat  Industries,  Ltd. 
P.O.  Box  292  Station  B 
London,  Ontario,  Canada    N6A  4V8 
519-681-2980 

Pachena  Scientific  and  Industrial  Electronics  Inc. 

7966  Winston  Street 

Burnaby,  B.C.,  Canada    \/5A  2H5 

604-420-2023 

Red  Pine  Instruments,  Ltd. 

RR  1 

Denbigh,  Ontario,  Canada  KOH  ILO 
613-333-2775 

Sy  stemware 

425  Mount  Pleasant  Road 

Toronto,  Ontario,  Canada    M4S  2L8 

416-481-9480 

Urban  Transportation  Associates 
7111  Hamilton  Hills  Drive 
Cinncinati ,  Ohio  45244 
513-232-5283 
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Appendix  6.2 

SURVEY  OF  AUTOMATIC  PASSENGER  COUNTER  USERS 


GENERAL  INFORMATION  ON  PROPERTY  AND  APC  USE 


Date  of  Interview  

Name  of  Transit  System  

Address  

city 

Name  of  Contact  Person  

Division  

Division's  Functions: 

Names  of  other  personnel  involved  with  APC  program: 

Names  Title/Division         Phone  No.  APC  Involvement 

*  What  is  the  size  of  your  transit  system  in  terms  of  fixed  route  service? 

Total  number  active  vehicles  including  spares  

Base  fleet  size   Peak  fleet  size  

*  What  is  the  size  of  the  population  serviced  by  your  system?  

*  How  is  ridership  distributed  along  routes?  (ie:  do  most  routes  have  a  major 
bus  stop,  or  is  ridership  spread  evenly  along  most  routes?)  If  there  are 
high  use  stops,  how  do  you  perceive  APC  error  at  these  STOPS? 


state  zip 

  Phone  Number. 

Title  


137 


How  many  buses  are  equipped  with  ARCS?  

number  of  buses 

Of  these,  how  many  are  operational  at  any  given  time?  

If  ARCS  are  installed  on  different  bus  types,  is  type  of  bus  a  factor  In  the 
success  of  the  system?  Explain: 


On  the  average,  how  many  person  hours  does  your  division  spend  using 
the  ARC  data  and/or  equipment?   PTE 


In  general,  for  what  purposes  do  you  use  ARC  information  or  equipment? 

OCreate,  evaluate  and  adjust  schedules  and  run  times 
()Rlan  and  justify  route  changes 
OEvaluate  marketing  strategies 

()Estimate  expected  revenue  (farebox  accountability) 
O Determine  fleet  needs 
OMonitor  driver  performance 
ODetermine  location  of  bus  stop  facilities 
()Section  15  reporting 
()Other  (Describe:) 


Generally,  which  type  of  ARC  system  do  you  use? 

0  Information  System:    report-oriented  for  planning  and  scheduling 

()  Control  System:    screen-oriented  operating  in  real-time. 

0  Integrated  System:    combined  information  and  control  system. 


(If  integrated  system  is  used)  To  what  extent  does  competition  for  use  of 
the  system  create  problems  or  conflicts?  How  have  you  resolved  or  do  you 
plan  to  resolve  these  problems? 


Are  you  satisfied  with  your  present  system?  in  general,  what,  if  any, 
changes  would  you  make  or  are  you  planning  to  make  to  your  present 
system? 
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APC  SYSTEM  COMPONENTS 


COUNTING  SENSORS 


What  type  of  sensors  do  you  use?  (make,  source,  date  of  purchase,  etc) 


What  types  of  APC  COUNTERS  do  you  use? 
() Infrared  beam  interruption 

Odual  beams 

()multiple  beams 
0 Reflective  Infrared  beams 
OTreadle  sensor  mats 
() Ultrasonic  Interruption  sensors 
QOther  (please  describe  in  detail) 


Where  are  these  counters  located  on  the  bus?  (describe  exact  location) 


What  are  the  maintenance  requirements  of  these  sensors? 


How  do  you  feel  about  this  equipment?  If  you  were  to  purchase  the 
counters  today,  what  would  you  do  differently  after  having  had  some 
experience  with  the  present  sensors? 
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ON-BOARD  MICROPROCESSING  UNIT  AND  FUNCTIONS 


UNIT  AND  ALGORITHM: 

*      What  type  of  microprocessor  do  you  use  on-board  the  bus?  (Describe  make, 
source,  and  date  of  purchase) 


*       What  functions  are  performed  by  the  counting  algorithm  of  this  unit?  (e.g. 
time  tags,  date  tags  location  and  passenger  data,  etc.) 


*       Discuss  electronic  operation  and  maintenance  requirements  and  costs: 


*       What  type  of  errors   have  you   encountered  with   the   sensors    or  the 
interpretation  of  the  logic  algorithm? 


*       Do  the  algorithms  of  this  unit  identify  failures  in  the  passenger  counting 
sensors?  How  is  this  accomplished? 


*       Are  errors  minimized  or  avoided  by  other  means?  Discuss: 


*       How  much  of  the  individual  vehicle  trip  readings  must  be  discarded  due  to 
bad  or  inconsistent  data? 
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DATA  RECORDS: 


What  types  of  data  are  obtained  and  stored  by  the  APC  Unit? 

Opassenger  boarding  counts 
()passenger  alighting  counts 
Ovehicle  arrival  times 
()  location  reference 

()run,  bus  number,  trip  I.D.  code  initialized  for  entire  run  or  trip. 
(Describe: ) 


How  is  data  input  activated?  ("A"  if  activates  data  input) 

Which  of  the  following  events  are  recorded?  ("R"  if  recorded) 

door  opening,  front  and  rear?  

door  closing,  front  and  rear?  

begin  of  idle  

end  of  idle  

time  between  stops  

distance  between  stops  

signpost  detection  

memory  space  overflow  

lift  action  for  handicapped  

(Describe  how  this  operates) 


Oother  (please  describe  in  detail) 


Comments: 


LOCATION  REFERENCING  METHOD: 


How  do  you  reference  location  of  data  input? 

Ocomputer  generated  comparison  of  APC  odometer 

reading  to  stop  by  stop  distance  file 

Ocomputer  program  to  search  APC  records  for  bus 

layover  intervals,  ie:  begining  and  end  of  idle 

events 

Osignpost  identification  systems  for  vehicle  trip 

and  stop -referencing 

Oother  (please  describe  in  detail) 
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*  Discuss  maintenance  requirements: 

*  Are  you  satisfied  with  this  method?  Discuss: 

DATA  STORAGE: 

*  What  type  of  data  storage  mechanism  does  this  unit  use? 

Ocassette  tape 
Osolid  state  memory 
Obubble  memory 
()  radio 
()infra-red 
Oother 

*  What  is  the  storage  capacity  of  this  unit?  bytes 

*  Are  you  satisfied  with  this  method?  Discuss: 

*  Is  this  method  compatible  with  automatic  transfer  of  on-board  data  to  a 
central  computer  facility? 

*  Discuss  make,  source  and  date  of  purchase  of  microprocessing  unit: 


*       Discuss  level  of  satisfaction  with  on-board  CPU  (What,  if  anything  would 
you  do  differently  if  you  purchased  this  unit  today?): 
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DATA  TRANSFER  DEVICE  AND  PROCESS 


What  type  of  data  transfer  mechanism  do  you  use? 

Oportable  recording  units  requiring  manual  operation 
C) automated  retrieval  systems 

Ocable  data  retrieval  system;   indicate  where   located,    ie:  fueling 

island,  etc. 

Oinfrared  data  transmission  to  receiving  sensor;  indicate  where 
located,  ie:  garage,  etc. 

()  radio  transfer 
Oother  (describe:) 


*  How  many  of  these  devices  do  you  use  for  ARCS?. 

*  Discuss  maintenance  requirements: 

*  Discuss  make,  source,  and  date  of  purchase: 


*  How  does  data  transfer  take  place?  Describe  step  by  step  process:  (How 
often  is  it  done,  who  does  it,  how  much  time  is  involved,  how  is  it  done? 
etc.) 


(If  manual  transfer  used)  what  are  the  costs,  errors,  and/  or  problems 
associated  with  this  method? 

Are  you  satisfied  with  this  method?  Discuss: 
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SIGNPOST  INFORMATION 


(IF  signpost  is  utilized)  Which  type  of  signpost  method  do  you  use? 
() sharp  signpost:  at  precise  locations  at  specific  points 

() roadside  narrow  beam  optical  scanners 

Omicrowave  transmitters 

Omagnets  imbedded  in  road  surface 

()other  (describe  in  detail) 


Obroad  signpost:  transmitting  coded  radio  signals 
periodically  received  by  buses  within  range 

Owith  software  to  reference  individual  stops 

(please  describe  software)* 


0 radio  frequency:   computer  analyzed  radio  signal 
triangulation 
OVLF 

Opulse  triangulation 

()AM  phase  lock 

Oother  (describe  in  detail) 


Oother  (describe  in  detail) 


How  many  signposts  have  you  acquired? 

Number  of  miles  apart  

Number  per  route  
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* 


Discuss  maintenance  requirements: 


Did  incorporating  signposts  require  modification  of  the  on-board  unit  to 
accomodate  additional  data?  If  so,  what  costs  did  this  incur?  To  what 
extent  did  this  increase  the  level  of  complexity  for  the  user? 


Comments  on  this  method  and  equipment: 

Are  you  satisfied  with  equipment?  If  not,  why  not? 


Discuss  source,  make,  and  date  of  purchase  of  signposts 
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STATIONARY  CPU  HARDWARE  AND  SOFTWARE 


HARDWARE; 


What  type  of  stationary  CPU  do  you  use  with  the  APC  system  at  a  central 
location?  Is  this  a  dedicated  unit?  What  users  can  access  data  from  this 
CPU?  Are  terminals  used  with  a  main  processing  unit?  how  many?  Is 
system  interactive? 


Did  you  purchase  this  unit  for  use  with  APC  system  or  was  it  already  at 
your  disposal  for  other  purposes? 


Discuss  source,  cost  and  time  of  purchasing  this  unit  and  terminals: 


SOFTWARE: 


Describe  software  functions  of  central  computer: 

() validation  checks  against  expected  behavior  on  each  instumented  vehicle 
Oappend  route  numbers  to  the  data 

Oappend  bus  stop  numbers  (replacing  'distance'  measurement  with  'true' 
location) 

Oappend  vehicle  assignment 
()append  run  number 
Oother  (describe:) 


What  other  information  must  be  created  and/or  entered  on  a  regular  basis 
for  the  software  to  operate?  ie:  schedule  changes,  etc. 
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How  complex  are  APC  programs  to  run  and  update  or  change? 


What  steps  do  you  recommend  to  deal  with  over-complexity? 


How  did  you  obtain  software  for  the  CPU?  (was  it  developed  in-house;  did 
you  purchase  canned  programs;  where?  make,  etc.) 


What  are  the  advantages  of  the  means  you  chose  to  obtain  software?  (ie:  if 
purchased,  how  reliable  is  the  source  for  updating  or  obtaining  additional 
packages  or  programs?  If  in-house,  are  costs  of  up-dating  software  and 
training  users  lessened?  discuss:) 


Describe  costs  and  pattern  of  purchase  of  this  software: 
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APC  GENERATED  REPORTS 


What  reports  are  produced  from  the  APC  data  on  ridership  activity? 


OPASSENGER  LOADING  PROFILES  (overloading  and  underutilization) 
Oaverage  passenger  loads 
()maxjmum  passenger  loads 
()  load/capacity 
() route  profiles 
( )niaximum  load  points 
Qboardings  by  stop 
Oalightings  by  stop 
() number  of  standees 
Otime  with  standees 

() standees  as  a  percent  of  seated  capacity 
Qother  (describe) 


OTIME  PERFORMANCE  (for  route  scheduling) 
Orunning  times 
Qarrival  times 
() departure  time 
()  layover  time 
() percent  on  time 
Ominutes  early/late 
Oaverage  speed  between  time  points 
Oschedule  adherence 
Oheadway  distributions 
Odwell  times 
()other  (describe) 


OPERFORMANCE  INDICATORS  (for  management) 
Opassenger  miles/kilometers 
()passengers  per  hour 
()boardings  per  mile/km 
()boardings  per  hour 
()revenue/cost  ratios 
Orevenue  miles/vehicle  miles 
Oother  (describe) 
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What  levels  of  detail  are  incorporated  in  your  APC  generated  reports? 

0  SPATIAL  DISAGGREGATION: 
() system  total 
Odivision  or  garage  total 
()  route  level 

Odriver  run  or  vehicle  block 

()bus  trip 

()  route  segment 

()bus  stop 

Oother  (describe) 

0  TEMPORAL  DISTRIBUTION 
() season 
Osign  up 
Omonthly  totals 
()totals  for  weekday.  Sat,  Sun 
Otime  periods  (AM,  MID,  PM,  EVE) 
( )hourly 

015  minute  periods  during  peak  traffic  hours 
Oother  (describe) 


REPORT  PRESENTATION 
( )tabular 

Ographical  -  color? 
()exception 
( )on-demand 
(Aperiodic 
Oother  (define) 


What  information  is  needed  to  produce  these  reports?  How  do  you  obtain 
this  information?  How  is  it  input  into  the  APC  data  file  or  otherwise 
integrated  into  the  program?  (e.g  computerized  schedule  data  used  to  time 
match  APCs  data  with  schedule,  etc.) 


How  easily  can  these  reports  be  accessed  for  further  data  manipulation? 


How  can  APC  data  be  integrated  with  other  information  (ie:  census  data, 
bid  documents,  origin  and  destination  studies,  etc.)? 


Can  APC  data  be  accessed  for  AD  HOC  reports?  How  is  this  done?  Describe 
cost  and  source  of  additional  software  procured  for  this  purpose: 
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APC  IMPACTS  ON  CURRENT  OPERATIONS 


*  What  type  of  route  structure  do  you  have? 
Oradial   Ogrld   Ofeeder  trunk   Oother  (Describe:) 

*  Describe  current  data  collection  techniques  you  use.  Do  you  use  a 
sampling  plan?  How  do  you  determine  an  appropriate  sample  size?  what  is 
the  level  of  accuracy  and  reliability  you  seek  to  achieve  with  your  current 
techniques? 


To  what  extent  has  the  use  of  the  APC  system  forced  you  to  alter  your 
data  collection  process?  Was  this  an  advantageous  change?  If  not,  how 
would  you  suggest  this  alteration  be  avoided  in  the  future? 


*  How  Is  the  APC  system  monitored  for  accuracy?  What  have  you  learned 
from  your  experience  with  APC  equipment  in  terms  of  accuracy  and 
reliability  of  the  data  obtained  from  the  system  you  now  use  and  from  other 
systems  you  have  used  in  the  past? 

*  How  have  APCs  effected  other  transit  functions  (ie:  scheduling, 
interlining,  maintenance,  etc.)? 


Have  APCs  been  cost  effective  for  your  property? 


*      Would  you  do  it  again? 


*       What  are  your  plans  for  future  use  of,  additions  to,  or  modifications  of 
your  present  APC  system?  discuss: 
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BACKGROUND  ON  APC  PURCHASE 


How  did  you  select  your  contractor?  On  the  basis  of  price  only  (bid)? 
Or  did  you  base  your  decision  on  qualifications  as  well  as  price  (RFP  or 
RFQ)?  How  many  responses  did  you  receive?  Did  you  have  separate  bids 
per  item  or  did  you  purchase  a  complete  system  at  one  time? 


Did  you  require  a  warranty  for  all  items?  how  long? 

Would  you  be  willing  to  send  us  a  copy  of  your  RFP  for  review? 
How  did  you  secure  funding  for  your  APCS  purchase? 

Notes  on  other  uses  of  data  from  other  divisions  using  the  APC  system: 
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COSTS  OF  APC  SYSTEM 


HARDWARE 

EQUIPMENT: 

Counting  Sensors  per  unit   total  purchase 

Date  of  purchase  

On-board  microprocessor  per  unit   total  purchase 

Date  of  purchase  

Signposts  per  unit   total  purchase 

Date  of  purchase  

Transfer  Device  per  unit   total  purchase 

Date  of  purchase  

Central  Processing  Unit  (Stationary)  total  cost 

Date  of  purchase  

*       Did  you  purchase  this  computer  for  use  with  APCS? 


If  you  purchased  these  items  as  a  package,  what  was  the  total  cost 

of  your  complete  system?   How  does  this  break  down  per 

item?  Estimate: 
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INSTALLATION  (Cost  or  person  hours  as  applies): 

Counting  Sensors  per  unit 

()ln-house       Ocontractor       Osupplier  Oother 

Microprocessing  Unit  per  unit 

()ln-house       Ocontractor       Osupplier  Oother 

Signposts  per  unit 

OIn-house       Ocontractor       Osupplier  Oother 

Transfer  Device  per  unit 

OIn-house       Ocontractor       Osupplier  Oother 

Stationary  CPU  

OIn-house       Ocontractor       Osupplier  Oother 


ANNUAL  MAINTENANCE  (cost  or  person  hours): 

Counting  sensors  average 

On-board  microprocessor  average 

Signposts  average 

Transfer  Device  average 

Stationary  CPU  average 

*  How  is  your  system  maintained? 

OIn-house     Ocontractor      Osupplier  Oother 

*  Comments  on  maintenance  costs: 
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SOFTWARE 


Development  of  analysis  and  reporting  software. 


()ln-house  Ocontractor  Osupplier  Oother 
File  creation: 


vehicle  assignments, 
scheduled  times  


File  update: 


vehicle  assignments, 
scheduled  times  


Other  Software  Costs:  Describe 
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Appendix  6.3 
Glossary 

Alighting:  deboarding 

APC  (Automatic  Passenger  Counter):  Hardware  and  software  used  in 
automatically  collecting  and  analyzing  data  on  passenger  counts,  running  times, 
and  bus  location  for  transit  planning,  scheduling,  and  management. 

Counting  sensors:  electronic  devices  that  transmit  a  signal  to  the  data 
collection  unit  when  passengers  board  and  deboard  the  bus.  Infrared  beams  and 
treadle  sensor  mats  are  the  most  commonly  used  counting  sensors. 

Data  Collection  Unit  (DCU):  device  used  to  collect  and  store  data  on-board  the 
bus.  DCU  contains  a  microprocessor,  a  clock,  and  location  board  or  other  unit 
to  receive  and  interpret  signpost  code  and  odometer  readings. 

Lighthead:  transmits  light  beam  to  either  a  reflector  or  a  receiver  in  infrared 
counters. 

Location  referencing:  general  term  defining  methods  of  locating  the  bus  for 
schedule  adherence  data  (ie:  signposts  reference  location  of  passenger 
activity) . 

Off  line  reporting:  Data  are  examined  in  hard  copy  reports  sometime  after  the 
events  occur.    APC  applications  are  off-line  information  systems. 

Portable  Data  Unit  (PDU):    DCU  (Data  Collection  Unit). 

Portable  Disk  Unit  (PDU):  device  used  to  retrieve  data  from  the  on-board 
storage  unit. 

Property:    Transit  agency. 

Real-time  Monitoring:  Monitoring  bus  activity  on  screens  in  "real-time",  or  "as 
it  occurs".    AVM  or  Automatic  Vehicle  Monitoring  Systems  operate  in  real-time. 

Relative  time:  the  time  elapsing  since  the  most  recent  event  (as  opposed  to 
absolute  time,  or  time  of  day  based  on  a  24  hour  clock).  For  example,  relative 
time  may  be  recorded  as  ±10  minutes.  The  interpretation  is  "±10  minutes  since 
the  bus  has  passed  a  signpost,  picked  up  passengers,  etc." 

Signpost:  devices  which  transmit  radio  signals  to  the  data  collection  units  on- 
board the  bus  via  special  signpost  antennae  located  atop  the  bus.  Signposts  are 
used  to  identify  bus  location. 

System  Controller:    DCU  (see  Data  Collection  Unit). 

Treadle  sensor  mat:  electronic  components  installed  under  the  stairwell  mats 
on  buses.  Passengers  are  counted  as  either  boarding  or  deboarding  depending  on 
the  sequence  in  which  they  step  on  the  mats  (ie:  "first  step-second  step" 
sequence  =  deboarding). 

Turnaround  time:  the  time  it  takes  for  data  to  be  collected,  analyzed  and 
presented . 
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NOTICE 

This  document  is  disseminated  under  tine  sponsorship  of  the 
U.S.  Department  of  Transportation  in  the  interest  of  information 
exchange.  The  United  States  Government  assumes  no  liability 
for  its  contents  or  use  thereof. 

The  United  States  Government  does  not  endorse  manufacturers 
or  products.  Trade  names  appear  in  the  document  only  because 
they  are  essential  to  the  content  of  the  report. 

This  report  is  being  distributed  through  the  U.S.  Department  of 
Transportation's  Technology  Sharing  Program. 
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